SuperAPI AI Directory

chinese-copyright-application

Office & productivity

View repository

Updated 10-15 18:30

About this skill

Chinese Software Copyright Application Material Generation

Core Principles

  • Application Form: Output directly as Markdown (.md) file for submission, not involved in LaTeX compilation.
  • Source Program, User Manual, Design Specification: Generate .tex files, compile to PDF with XeLaTeX.

v1.1 Key Changes

  • Application form carrier changed from LaTeX→PDF to Markdown (entry issues caused by line breaks in PDF text extraction)
  • Main function word count: 200 words → 500–1000 words (500–600 recommended)
  • Addedversion number consistency verification(during the information collection stage, check whether the version string in the project matches the target version number)
  • Addedlegacy code identification(mockData/util.js templates/logs etc. should not enter the identification materials)
  • Design Specification §4 Detailed Design mandatory 6-paragraph structure + bidirectional correspondence of module coverage
  • Source program PDF must be exactly 60 pages, providing --front-lines / --back-lines fine-tuning parameters

Quick Start

  1. Environment check and installation guidance
  2. Collect copyright owner information and key parameters
  3. Analyze project structure and code
  4. Generate four LaTeX documents + compilation script
  5. Generate screenshot checklist
  6. Run consistency verification

Workflow

Step Zero: Environment Check

The application form is Markdown,it can be obtained without a LaTeX environment. The LaTeX environment is only used to compile the three PDFs (source program, user manual, design specification).

Execute xelatex --version detection.

If already installed: continue to the next step.

If not installed: inform the user that all Markdown/LaTeX source files + Markdown application form can be generated first, and the three PDFs can be compiled after LaTeX is installed; ask whether to install immediately. After the user agrees, execute the following commands:

  • macOS:brew install --cask basictex && sudo tlmgr update --self && sudo tlmgr install ctex xecjk fancyhdr lastpage fancyvrb tabularx enumitem float xcolor longtable collection-fontsrecommended
  • Linux:sudo apt install texlive-xetex texlive-lang-chinese texlive-latex-extra texlive-fonts-recommended
  • Windows: guide the user to install the full TeX Live version (https://www.tug.org/texlive/)

Step One A: Version Number Consistency Verification (do this first)

This is thefirst opinionfrom the last time (Jixiang V1.0 software copyright serial number 2026R11L0626727) that was rejected for correction: the application form filled in V1.0, but utils/config.js wrote version: '1.1.1', and the screenshot corner label was also V1.1.1, which was caught by the examiner at first glance. This step must be done before collecting software parameters.

Operation Process:

  1. First ask the user "what version number is being applied for this software copyright" (usually V1.0 for a first application).

  2. Then scan all version number strings in the project:

    # 配置文件中的 version 字段
    grep -rEn '"version"\s*:\s*"[0-9]+(\.[0-9]+)+"' <项目路径> \
      --include='*.js' --include='*.ts' --include='*.json' \
      --exclude-dir=node_modules --exclude-dir=miniprogram_npm
    
    # 页面 footer / 关于页里硬编码的版本号
    grep -rEn 'V[0-9]+\.[0-9]+|版本.*[0-9]+\.[0-9]+' \
      <项目路径>/pages <项目路径>/components <项目路径>/src 2>/dev/null
    
  3. If the user has already provided a running screenshot directory, remind the user to check whether the bottom-right corner/about page/startup page of the screenshots contains a version number.

  4. List the scan results in table form:All occurrence locations + corresponding version strings。

  5. If any inconsistency is found (the version number in any location ≠ the version number the user intends to apply for),you must stopand let the user decide: "Which version number should ultimately be used in the application?" and clearly inform the user: before submitting the application, all occurrences must be unified (including redoing screenshots).

  6. Only if all are consistent can you proceed to the next step.

See requirements.md。

Step 1: Information Collection

Collect information in two rounds.

First round: Copyright owner information

First check whether the following exists in the project root directory or the user's working directory: copyright-owner.json。

If it already exists: read the file contents, show them to the user, and confirm whether there are any changes. If the user confirms there are no errors, use it directly and skip to the second round.

If it does not exist: for first-time use, guide the user to provide the information and save it. First ask whether the copyright owner is an individual or a company, then collect the corresponding information.

For an individual, provide: name, ID number, address, postal code, contact person, phone, email.

For a company, provide complete business registration information (refer to requirements.mdthe "Copyright Owner Information" section): full company name, Unified Social Credit Code, enterprise type, legal representative, registered capital, registered address, registration authority, business license registration date, contact person, phone, email.

After collection is complete, save the information as copyright-owner.json, in the following format:

{
  "type": "企业",
  "name": "星辰科技(北京)有限公司",
  "credit_code": "91110108MA01EXAMPLE",
  "enterprise_type": "有限责任公司",
  "legal_representative": "张三",
  "registered_capital": "伍佰万元整",
  "address": "北京市海淀区中关村大街1号",
  "registration_authority": "北京市海淀区市场监督管理局",
  "license_date": "2022年6月15日",
  "contact": "",
  "phone": "",
  "email": ""
}

This file can be reused directly for subsequent applications; the copyright owner information only needs to be filled in once.

Second round: Key software parameters

Automatically analyze the project and prefill suggested values for the user to confirm:

Parameter Description
Full software name Must end with the two characters "软件"(e.g., "智慧记账软件"), be distinctive, and be completely consistent in all documents. If the name provided by the user does not end with "软件", automatically append it
Version number V1.0 (use V1.0 uniformly for first-time applications)
Development completion date The date the software actually completed development
First publication date The date the software was first launched/released (≥ development completion date)
Source code volume The actual total number of lines of code in the project (can be automatically counted and then confirmed by the user)

Date constraint: development completion date ≤ first publication date < application date. This is automatically validated during generation; if it does not comply, remind the user to modify it.

Step 2: Project analysis and source program generation

Run scripts/analyze_and_generate_source.py to complete project analysis and source program .tex generation:

python3 scripts/analyze_and_generate_source.py <项目路径> \
  --name "软件全称" \
  --version "V1.0" \
  --owner "著作权人名称" \
  --date "2025年4月30日" \
  --output copyright-materials/

The script automatically completes:

  1. Detect the project type (WeChat Mini Program/Web/Node.js, etc.)
  2. Traverse code files, excluding irrelevant directories such as node_modules
  3. Identifylegacy code candidates(mockData, util.js templates, logs, etc.), and output them to the JSON's legacy_candidates field
  4. Count valid lines of code (excluding blank lines and pure comment lines), and output the line count distribution by file type
  5. Sort by file priority, remove blank lines, extract the first 30 pages + last 30 pages of code, and generate the source program .tex file
  6. Output project_analysis.json for reference in subsequent document generation

Legacy code exclusion rules(automatic identification by default + user decision):

The script scans the following patterns as legacy code candidates,lists them but does not automatically exclude them:

  • mockData*.js / mock*.js / fakeData*.js — fake data for development use only
  • utils/util.js — the WeChat Mini Program default template's formatTime boilerplate (condition: file < 1KB or contains only template functions)
  • pages/logs/** — the log page of the WeChat Developer Tools default template
  • Empty files, placeholder files, temporary debugging code

After Claude obtains legacy_candidates , it mustlist them and ask the userwhether to exclude them, and after confirmation rerun the script via the --exclude-pattern parameter. This is to avoid code in the source code identification materials that "has no corresponding module that can be written in the documentation" (the second biggest reason Jixiang was rejected last time).

Layout empirical values(10pt + \small Verbatim + top/bottom 2cm, left/right 1.5cm margins, calibrated based on actual measurements):

Parameter Value Description
Standard page capacity 50 lines/page Number of code lines on a full page
First page capacity 40 lines The title area occupies about 10 lines of space
First page of the last 30 pages 48 lines The separator title occupies about 2 lines of space
Target for the first 30 pages 1490 lines 40 + 29×50 (can be overridden with --front-lines )
Target for the last 30 pages 1498 lines 48 + 29×50 (can be overridden with --back-lines )
Total target 2988 lines Number of code lines after removing blank lines

When the amount of code is less than 2988 lines, the script uses all the code and does not force 60 pages.

The total_lines_effective output by the script is the "source program volume" in the application form.

60-page hard constraint (important): after the source program PDF is compiled, itmust be exactly 60 pages(unless the project code itself is less than 60 pages). One page more or one page less is a format non-compliance. After compiling, use pdfinfo <软件全称>源程序.pdf | grep Pages to verify; if it is incorrect, adjust the --front-lines / --back-lines parameter (default 1490 / 1498, try ±2~5 lines each time) to regenerate and recompile.

Step 3: Generate four documents

See references/requirements.mdfor the LaTeX writing standards for all documents. See the corresponding .tex template file in the references directory for each document's template.

Output folder and naming

Output directory:copyright-materials/

Create the directory structure before generating documents:

mkdir -p copyright-materials/images

The file naming convention is "full software name + document type", for example:

  • 智慧记账软件著作权登记申请表.md(Markdown submitted directly, not compiled)
  • 智慧记账软件源程序.tex / .pdf
  • 智慧记账软件用户手册.tex / .pdf
  • 智慧记账软件设计说明书.tex / .pdf
  • build_all.sh
  • images/(image directory, where the user will later place screenshots)

3.1 Copyright Registration Application Form (Markdown)

Template:application-form-template.md

Medium: directly generate the .md file,not involved in LaTeX compilation. The application form itself has no hard format requirements; Markdown tables + paragraphs are sufficient.

Format requirements:

  • Use Markdown tables to organize fields (| 字段 | 内容 |)
  • The main function paragraphs are written outside the table, expanded in sections
  • Divided into: Basic Information, Copyright Owner Information, Developer Information, Software and Hardware Environment Information, Basic Software Information, Software Technical Features, Software Classification, Remarks
  • The application form fields have strict character limits (see the "Character Limits" section in requirements.md for details); they must be validated after generation

Character Limits Quick Reference:

  • Hardware environment/Operating system/Development tools/Running platform/Supporting environment: each ≤50 characters
  • Development purpose/Target field: each ≤50 characters
  • Main functions: 500–1000 characters (500–600 characters recommended to reduce errors)
  • Technical features: ≤100 characters

3.2 Source Code

Automatically generated by the script in step two; no manual writing required. For generation rules, see requirements.md"Source Code Documentation Requirements".

3.3 User Manual

Template:user-manual-template.tex

Content structure:

  1. Software Introduction (overview + main features)
  2. Function Overview (function list + applicable scenarios)
  3. Installation and Usage Instructions (system requirements + access method + login instructions)
  4. Main Function Description (operating steps for each function, with screenshots)
  5. Precautions
  6. Technical Support

Screenshot Requirements:

  • Define the \screenshot{文件名}{标题} macro, width 0.35\textwidth
  • For screenshots not yet provided, still place the \screenshot call in LaTeX
  • Also output a screenshot list (see step four)

3.4 Design Specification

Template:design-doc-template.tex

Content structure:

  1. Software Overview (introduction + development background + design goals)
  2. Requirements Analysis (functional/performance/security requirements)
  3. Overall Design (system architecture + module division + technology selection + operating environment)
  4. Detailed Design(each module expanded in a 6-section structure, with screenshots)
  5. Data Structure Design
  6. Interface Design (internal interfaces + external API list)
  7. Interface Design (with screenshots)
  8. Security Design
  9. Test Design

§4 Hard Rules for Detailed Design (bidirectional correspondence + 6-section structure):

This was the second biggest reason the previous submission (Jixiang V1.0 software copyright) was rejected and required correction. For details, see requirements.md Design Specification and Source Code Correspondence Rules。

  • Bidirectional correspondence: Every module that appears in the source code identification materials musthave a corresponding subsectionin §4 Detailed Design; and vice versa.
  • Subsection naming: Each \subsection heading should correspond to the project's actual directory or file name (e.g., pages/index、utils/api.js、utils/marketHelper.js); do not invent abstract Chinese names.
  • 6-section structure: Each module is expanded according to the following 6 sections (no longer the old version's two sections of "module function + processing flow"):
    1. Module Responsibilities
    2. Inputs and Outputs
    3. Key Algorithms and Processing Logic
    4. State and Cache Management
    5. Dependencies with Other Modules
    6. Processing Flow

Reference design-doc-template.tex already has a built-in 6-section structure example.

Step Four: Screenshot Management

Analyze the project code (page files, popup components, modal dialogs, etc.) and generate a screenshot checklist screenshot-list.md:

| 编号 | 文件名 | 描述 | 触发方式 | 使用位置 |
|------|--------|------|----------|----------|
| 01 | 图1-首页空状态.png | 首页空状态 | 首次进入首页 | 用户手册§3、设计说明书§4.1 |
| 02 | 图2-搜索结果列表.png | 搜索结果 | 输入关键词搜索 | 用户手册§4.1、设计说明书§4.1 |

In the LaTeX document, \screenshot{文件名}{标题} macro already has a built-in images/ path prefix, so users only need to place the screenshots in the images/ directory with file names matching those in the checklist, and they will be found automatically during compilation.

Deliver the screenshot task to the user

After the initial document draft has been generated,pause the automated workflow, and output the following operation instructions to the user (replace <输出目录> with the actual path):


The initial document draft has been fully generated. Next, you need to manually capture screenshots of the software interface.

Screenshot save path:<输出目录>/images/

Please follow the screenshot checklist above, capture the corresponding software interface screenshots one by one, and save them to this directory. Keep the file names consistent with the "File Name" column in the checklist (e.g. 图1-首页.png)。

After the screenshots have been added, reply to me and I will recompile all documents to generate the final PDF.


After the user confirms the screenshots are complete, continue with Step 5 (Compilation) and Step 6 (Verification).

Step 5: Compilation Script

Generate build_all.sh, template see references/build-script-template.sh。

Script key points:

  • Set PATH to include the TeX path
  • The DOCS array only compiles 3 items(User Manual, Design Specification, Source Program); the application form is Markdown and not compiled
  • Each .tex file is compiled twice (to ensure correct page number references)
  • Clean up temporary files such as .aux/.log/.out
  • Output the file size of each PDF

After compilation is complete,use pdfinfo <软件全称>源程序.pdf | grep Pages to verify that the source program PDF is exactly 60 pages. If it is not 60 pages, adjust the --front-lines / --back-lines parameter to regenerate the .tex and then compile again.

Step 6: Consistency Verification

After all documents have been generated, automatically verify the following content and output a verification report:

Verification Item Verification Location
Version number consistency (first item) Project source code (package.json / config.js / About page footer), runtime screenshots, application form, headers and body text of each document
Full software name Application form, source program header and first page, user manual title/header, design specification title/header
Version number In the headers and body text of all documents
Source code volume The number in the application form = the number marked on the first page of the source program document
Copyright holder name First page of each document
Date Dates referenced in each document are consistent
Main function word count 500 ≤ word count ≤ 1000 (parsed from the application form Markdown)
Other field word counts Development purpose/target domain ≤50 characters, technical features ≤100 characters, software/hardware environment field ≤50 characters
Module coverage (bidirectional) Each module in Design Specification §4 ↔ code files appearing in the first 30 pages + last 30 pages of the source program
Source program page count pdfinfo shows exactly 60 pages (unless the project code is less than 60 pages)

Fields are parsed from Markdown: The application form is Markdown, and the verification script parses table rows by| 字段 | 内容 |) and the body text of the "Main Functions of the Software" section to retrieve data; different from the old LaTeX parsing logic.

If the validation passes, output "✓ Consistency check passed"; otherwise, list the inconsistent items.

Unified LaTeX Formatting Standards

The following standards apply to the application form, user manual, and design specification (the source code document is an exception and has its own dedicated standards):

Page Setup

\documentclass[a4paper,12pt]{article}
\usepackage[UTF8,heading=true]{ctex}
\usepackage[top=2.5cm,bottom=2.5cm,left=2.5cm,right=2.5cm]{geometry}

Header and Footer

\pagestyle{fancy}
\fancyhf{}
\fancyhead[C]{软件全称V1.0\quad 文档类型}
\fancyfoot[C]{第 \thepage\ 页\quad 共 \pageref{LastPage} 页}
\renewcommand{\headrulewidth}{0.5pt}
\renewcommand{\footrulewidth}{0.5pt}
\fancypagestyle{plain}{\pagestyle{fancy}}

Header format:软件全称V版本号 文档类型(e.g., Smart Accounting Software V1.0 User Manual) Footer format:第 X 页 共 XX 页 Both the header and footer have a separator line (0.5pt)

Chinese Typography

\setlength{\parindent}{2em}          % 段首缩进 2 字符
\setlength{\parskip}{0.3em}
\renewcommand{\baselinestretch}{1.3}  % 1.3 倍行距

Lists

\begin{itemize}[leftmargin=2em]
\begin{enumerate}[leftmargin=2em]

Screenshot Macro

Set the image search path in the document preamble, and define the screenshot macro:

\graphicspath{{images/}}

\newcommand{\screenshot}[2]{%
  \begin{figure}[H]
    \centering
    \includegraphics[width=0.35\textwidth]{#1}
    \caption{#2}
  \end{figure}
}

When calling, only \screenshot{图1-首页.png}{首页}is needed, and LaTeX will automatically search in the images/ directory for the image file.

Document First Page Structure

The first page of every document follows a unified format:

\begin{center}
  {\LARGE\bfseries 软件全称\quad 文档类型}
  \vspace{0.8em}
  {\large 著作权人:公司全称}
  \vspace{0.3em}
  软件版本:V1.0\qquad 发布日期:YYYY年M月D日
\end{center}

Handling of Special Project Types

WeChat Mini Program

  • Software category: Mobile application software — Mini Program
  • Operating platforms: iOS, Android, Windows, macOS, HarmonyOS (WeChat client)
  • Runtime support environment: WeChat client (any version that supports Mini Programs)
  • Technical characteristic type selection: Mini Program

Web Application

  • Software category: Application software — Web application
  • Operating platforms: Windows, macOS, Linux (browser)
  • Runtime support environment: Chrome/Firefox/Safari and other browsers

Mobile App

  • Software category: Mobile application software — App
  • Operating platforms: List according to actual support (iOS/Android/HarmonyOS, etc.)

Cross-platform Projects

  • Electron application: Windows, macOS, Linux
  • Flutter/React Native: iOS, Android (if desktop is supported, add Windows, macOS, Linux)

LaTeX Environment Dependencies

See "Step Zero" for the environment check and installation process.

Note: The application form is Markdown,does not require LaTeX, and can be completed independently. LaTeX is only used for compiling the three PDFs: source code, user manual, and design specification.

Required Packages:ctex、xecjk、fancyhdr、lastpage、fancyvrb、tabularx、enumitem、float、xcolor、longtable、graphicx、hyperref、array、geometry

Compilation Command:xelatex -interaction=nonstopmode 文件名.tex(run twice)

Reference Documents