aj-copyright-writer

AJ Copyright Writer

Generate high-quality, business-consistent software copyright registration materials. Format compliance is only the baseline; modules, source code, documentation, interfaces, and application form must jointly present the software's proprietary business expression, and must not merely reuse the same code or text skeleton after changing names.

Required Resources

• Full process and directory conventions:references/workflow-contract.md
• Module, source code, and documentation writing:references/material-writing-rules.md
• Hard rules for registration materials:references/software-registration-rules.md
• Prototype style:references/prototype-ui-style.md
• When selecting an operation manual:references/operation-manual-template.md
• When selecting a software design specification:references/software-design-template.md
• After the operation manual is completed:references/operation-manual-humanizer.md
• After the software design specification is completed:references/design-specification-humanizer.md

The National Copyright Administration's 2025 copyright policy may only be used as industry background, and must not be treated as the operating rules for software registration materials. The registration rules are based on the "Measures for the Registration of Computer Software Copyright" and this skill's software-registration-rules.md .

{baseDir} indicates this SKILL.md the directory where it is located. All scripts use the absolute resolved path of {baseDir}/scripts/... for execution.

Input and Mode

Required input:SOFTWARE_NAME。

Optional input:

• SOFTWARE_VERSION: default V1.0。
• Output directory: default copyright-materials/{software_slug}-{YYYYMMDD-HHMM}/。
• MODE：normal or correction. Only automatically select correctionwhen the user provides a correction notice or explicitly requests correction; for a first application, use normal。
• Existing code, documentation, screenshots, correction notices, and historical material directories.
• Actual technology stack. When the user does not specify one, automatically select a self-consistent technology stack based on the software type.
• Document type:operation-manual or design-specification。
• Prototype mode: default HTML; use image mode only when the user explicitly requests an image model.

Correction mode always creates a new output directory and does not overwrite the original materials. First analyze the problems in the old materials, then reselect the business content; it is prohibited to only change variable names, use synonymous substitutions, or shuffle the order of paragraphs.

Formal Output

01.spec/spec.md
02.modules/01.md ... 10.md
03.prototype.style/selection.md
03.prototype.html/*.html 或 03.prototype.prompt/*.md
04.prototype/batch.json、*.jpg
05.code/01-模块名称.txt ... 10-模块名称.txt
06.document/${SOFTWARE_NAME}_操作手册.md/.docx
或 06.document/${SOFTWARE_NAME}_软件设计说明书.md/.docx
07.code.full/${SOFTWARE_NAME}_代码.docx
08.application-info/${SOFTWARE_NAME}_软著申请表信息.txt
09.originality-audit/source-manifest.json
09.originality-audit/originality-report.json
09.originality-audit/originality-report.md

09.originality-audit is an internal quality inspection directory, and the text in it must not be copied into 01—08 formal materials. Formal materials must not contain generation process explanations such as "this article is a draft", "AI-generated", "templated material", "inference-based extension", "extended settings", or "originality audit results"; in software names and real business terms, AI、合同模板 etc. must be retained normally.

Workflow

1. Research and Business Anchors

1. Use the software name to search official websites, product materials, industry standards, and authoritative business materials.
2. Extract the software's proprietary business objects, fields, states, rules, calculation criteria, exception scenarios, roles, and industry terminology.
3. Write this content into a formal software specification, including positioning, users, scenarios, business processes, architecture, data objects, functional and non-functional requirements.
4. Do not include source classification, assumption statements, or generation notes in the formal specification.

The business anchors are the sole standard for subsequent consistency. Code, interfaces, documentation, and application form must not fall back to generic expressions applicable to any system.

2. Fixed generation of 10 core modules

• Exactly generate 02.modules/01.md to 10.md, each module contains 3–5 function points.
• At least 8 modules must be industry or business core modules; general modules such as login, user, role, permission, log, dictionary, settings, and help must not exceed 2 in total.
• Module names, function names, fields, statuses, business rules, and exception branches must use the industry semantics of this software.
• Each module must explain in "Module Positioning" how it reflects the representative capabilities of this software, but do not use exaggerated promotion or review rhetoric.
• It is prohibited to use 数据管理 / 信息维护 / 统计分析 and other generalized names to occupy core modules.

After generation, run:

python3 {baseDir}/scripts/validate_outputs.py \
  --spec-md 01.spec/spec.md \
  --module-dir 02.modules

3. Select representative documents

In principle, generate only one type of identification document, selected according to the following priority:

1. The document type explicitly specified by the user.
2. For interaction, approval, scheduling, and operations software, select the operation manual.
3. For algorithm, backend service, data processing, device access, and protocol parsing software, select the software design specification.
4. When receiving a correction opinion that "the document is highly templated," select the type that better presents representative business expression; if the core value is embodied in internal processing rules, prioritize the design specification.

For each set of materials, select only one main identification document, and do not mechanically generate both at the same time. Record the selection result and reason internally, and present only the software content in the formal document.

Set DOCUMENT_TYPE=operation-manual|design-specification、DOCUMENT_BASENAMEand DOCUMENT_SELECTION_REASON. When selecting the design specification, you must first read software-design-template.md, and after the draft is completed, execute its professionalism check.

4. Generate prototypes and screenshots

When interface materials are needed, first read prototype-ui-style.md, recommend an industry-matching style and have the user confirm it. Generate selection.md before writing HTML or image prompts.

HTML must be self-contained, use Chinese business fields, real statuses, and reasonable mock data, be fixed at 1920×1080, and not depend on CDNs, remote fonts, or APIs. Pages must not display copyright ownership, development company, technical support, producer, or contractor attribution.

The operation manual must generate at least 10 module home pages, and generate independent screenshots for 40%–60% of complex function points. Generate 00-loginonly when the software truly has an account login flow; when there is no login flow, use the real entry, home page, or task start page, and use --no-loginin screenshots and validation commands. The software design specification should use only representative views that can prove the system structure, core processes, or key processing results, and should not create blank backend pages just to make up the number.

HTML mode:

python3 {baseDir}/scripts/screenshot_html_prototypes.py \
  --html-dir 03.prototype.html \
  --output-dir 04.prototype \
  --module-dir 02.modules \
  --batch-file 04.prototype/batch.json \
  --viewport 1920x1080

When the software has no login flow, append validate_outputs.py in the screenshot script and subsequent --no-login。

commands

5. Generate representative source programs

• Technology stack
• Prefer the user's real technology stack; otherwise, select a self-consistent solution according to the software type.
• The technology stack must run through the specification, code, design document, and application form.
• The 10 code files are organized by architectural responsibilities and business modules, and each file is not required to contain both frontend and backend.

Source code must have coherent syntax and consistent types and interfaces, and must not write "for example only" pseudocode.

Selected content

Prefer to include domain services, state transitions, rule determination, calculation or matching algorithms, data conversion, protocol parsing, complex validation, permission boundaries, exception recovery, and audit trails.

• Excluded:
• Environment configuration, build configuration, startup glue, and pure routing registration;
• DTOs or entities with only getters/setters and no business behavior;
• Empty methods, empty interfaces, empty components, TODOs, and placeholder pages;
• Auto-generated clients, third-party libraries, and framework source code;
• Repeated CRUD that only replaces class names or field names;
• Repeated comments with no business meaning.

Do not mechanically delete necessary imports from selected business files. Low-value files should be excluded while maintaining the structural integrity and readability of the selected source code.

Line count and order

• 05.code Contains exactly 10 编号-模块名称.txt files.
• Do not set a uniform line count for individual files; complex modules naturally contain more code.
• The 10 files total at least 3000 non-empty source lines, to satisfy 60 pages at 50 lines per page.
• Comments only explain business rules, state transitions, boundaries, and non-obvious logic; do not set a mechanical comment ratio target.
• 05.code Normal blank lines in source code may be retained to maintain readability; ignore blank lines when counting and composing the code DOCX. Source code must not contain copyright wording.

6. Write formal differentiation documents

The operation manual organizes chapters based on real tasks, using different approaches for task handling, review closure, monitoring and disposal, analysis and queries, batch import, and rule configuration, rather than making all functions repeat the same paragraph skeleton. All buttons, fields, statuses, and prompt messages must be findable in the corresponding interface.

The software design specification organizes content around architectural views, domain models, state transitions, core processing flows, algorithm inputs and outputs, interface contracts, data consistency, and exception recovery. The main text directly explains business objects, trigger conditions, processing actions, and results, without vague expressions such as "aims to," "empowers," "comprehensively improves," or "forms a closed loop." Do not mechanically expand the ten modules into ten isomorphic descriptions, and do not append generative mapping sentences such as "corresponding files" or "this section is implemented by..." at the end of chapters. If traceability between design and implementation truly needs to be reflected, use a "design-implementation traceability table" only at the end of the document to list logical components, core classes/services, and key methods, without showing internal directories, numbered code package file names, or file extensions. After the draft is completed, follow design-specification-humanizer.md to perform one language cleanup, without changing verified fields, statuses, rules, and implementation symbols.

Write formal Markdown directly into 06.document, and do not save formal artifacts with .draft names. Convert to Word:

python3 {baseDir}/scripts/markdown_to_docx.py \
  --input "06.document/${DOCUMENT_BASENAME}.md" \
  --output "06.document/${DOCUMENT_BASENAME}.docx" \
  --template "${DOCUMENT_TEMPLATE:-}"

When no template is provided, the conversion script uses an A4 Chinese technical document style: Chinese body text in SimSun 10.5 pt, English and numbers in Times New Roman; Chinese headings in SimHei, English in Arial. Fonts are written into both Word's East Asian font and Latin font properties, without relying on system default fonts. Tables, figure captions, and lists follow the same font rules.

7. Perform an internal originality audit

Run before generating the formal code DOCX:

python3 {baseDir}/scripts/audit_originality.py \
  --code-dir 05.code \
  --module-dir 02.modules \
  --document "06.document/${DOCUMENT_BASENAME}.md" \
  --document-type "${DOCUMENT_TYPE}" \
  --document-selection-reason "${DOCUMENT_SELECTION_REASON}" \
  --output-dir 09.originality-audit

If the user provides historical materials, append --comparison-corpus /path/to/history。

The audit blocks the following issues: empty implementations, explicit placeholder code, low-value files, excessive precisely duplicated code blocks, more than two generic modules, multiple sets of templated document paragraphs, documents missing core modules, and high similarity to historical materials. Uncertain indicators such as structural similarity only produce warnings. Audit thresholds are internal quality heuristics, not public standards of registration authorities.

If the audit fails, return to the module, code, or document step for substantive rewriting; do not use --allow-high-risk to generate formal deliverables.

8. Generate a 60-page code document

python3 {baseDir}/scripts/build_code_docx.py \
  --code-dir 05.code \
  --source-manifest 09.originality-audit/source-manifest.json \
  --originality-report 09.originality-audit/originality-report.json \
  --output "07.code.full/${SOFTWARE_NAME}_代码.docx" \
  --software-name "${SOFTWARE_NAME}" \
  --software-version "${SOFTWARE_VERSION:-V1.0}"

The code documentation must be 60 code pages, 50 lines per page, Songti small five, left-aligned, single-spaced. The header name and version must match the application form, and the page number is in the upper right corner. If it exceeds 3000 lines, take the first 1500 lines and the last 1500 lines of the continuous source code stream according to the ordinary deposit standard, and the last page is the end-of-program part.

9. Generate application form information

Generate 08.application-info/${SOFTWARE_NAME}_软著申请表信息.txt. The hardware environment, operating system, development tools, runtime platform, supporting environment, development purpose, and industry each must not exceed 50 characters; the main functions must not exceed 200 characters; the technical features must not exceed 100 characters.

The programming language and version are read from source-manifest.json , and the source program volume uses the total non-empty line count of 10 code files. The software type is selected from APP、游戏软件、教育软件、金融软件、医疗软件、地理信息软件、云计算软件、信息安全软件、大数据软件、人工智能软件、VR软件、5G软件、小程序、物联网软件、智慧城市软件 .

10. Final verification

python3 {baseDir}/scripts/validate_outputs.py \
  --code-dir 05.code \
  --source-manifest 09.originality-audit/source-manifest.json \
  --originality-report 09.originality-audit/originality-report.json \
  --document-md "06.document/${DOCUMENT_BASENAME}.md" \
  --document-docx "06.document/${DOCUMENT_BASENAME}.docx" \
  --code-docx "07.code.full/${SOFTWARE_NAME}_代码.docx" \
  --application-info-txt "08.application-info/${SOFTWARE_NAME}_软著申请表信息.txt" \
  --software-name "${SOFTWARE_NAME}" \
  --software-version "${SOFTWARE_VERSION:-V1.0}"

Delivery check

• Whether there are exactly 10 modules and 10 numbered code files, and at least 8 are business core modules.
• Whether the tech stack is self-consistent, and whether import-only, configuration, accessor, empty shell, generated code, third-party code, and duplicate CRUD have been removed.
• Whether the formal document type is suitable for the software, whether it avoids repetitive sentence patterns and covers all core modules.
• Whether the design specification does not contain numbered source file names, extensions, internal directories, and generative expressions such as "landed by...".
• Whether the names, fields, statuses, tech stacks, and versions in the documents, screenshots, code, and application form are consistent.
• Whether the internal audit is pass, and whether the source code fingerprint is still consistent with that at the time of the audit.
• Whether the code DOCX is 60 pages, 50 lines per page, and whether the header and page numbers are correct.
• Whether the formal materials contain no process explanations such as draft marks, AI-generated, templated materials, inference-based expansion, and internal audit results, while retaining the software name and real business terminology.

The final reply only lists the output directory, document type, core files, tech stack used, template usage, verification results, and unfinished items, and does not paste the entire code or documents into the chat.