software-copyright-writer

Software Copyright Writer

Overview

Use this skill to handle the complete process of "writing a software copyright based on the code repository and official website materials," rather than just writing a general introductory document. It is aimed at any software product or platform project, and is not tied to a specific product, technical framework, or industry.

First determine how many decent software copyright topics can actually be broken out of the repository, then supplement materials, write the main text, organize the original source code, capture web page evidence, and export .docx. If the repository size simply cannot support the quantity the user wants, point that out directly; do not force topics just to make up the number.

The repository and GitHub are only used as internal analysis input. The final software copyright main text must use the formal description register of "software/system/platform/product," introducing product functions, business processes, running interfaces, and technical implementation; do not write it as a code repository analysis report.

Compliance Boundary

This skill is only for organizing application materials for real software projects; it is not for forging software, forging screenshots, forging ownership, fabricating functions, or packaging source code that does not exist.

Design mockups, marketing pages, or login pages must not be passed off as actual running interfaces
The copyright owner, filing page, trademark certificate, or copyright notice must not be fabricated
Highly repetitive topics must not be forcibly split apart just to make up the quantity
Third-party source code, dependency code, or third-party copyright information must not be submitted as one's own source code
When materials are insufficient, gaps and risks must be listed; they must not be directly fabricated to fill them in

Output Mode

By default, adopt the "one-shot final draft" mode:

Only when the topic is unclear, the quantity is unreasonable, or materials are missing is it permissible to stop and ask questions or provide candidate options
Once the topic has been confirmed and the materials are sufficient, do not output an outline, half-finished product, sectioned draft, or intermediate explanation
Directly output the complete software copyright main text in one go, with a target volume of "per page 30 lines, about 30 pages, total word count 3w-4w, usually about 3.5w”
The source code files must likewise be output completely in one go; do not paste code in batches
If the user directly requests batch output such as "give me 5 software copyrights," and the information is already sufficient, then complete all documents consecutively without interrupting for confirmation on each one

Workflow

1. Collect input

First collect this information:

Required:代码仓库、官网页面、软著数量
Optional:指定模块、已有截图、Logo/商标注册证、域名备案页、著作权人全称、偏粗拆/细拆

When key input is missing, first stop at the material confirmation stage; do not start writing directly.

Use references/intake-checklist.md to check material completeness and hard constraints.

2. Understand the repository and generate candidate topics

First look at the repository structure, README, core directories, and page entry points to determine which capabilities can be independently described as one software copyright topic.

A topic must simultaneously satisfy most of these conditions:

Has a clear business goal
Has an independent functional closed loop
Has actual running screenshots that can accompany it
Has a code scope that can point to that topic
Can write a main text clearly distinguishable from other topics

If the user specifies a module:

First determine whether the module size is sufficient to support multiple software copyrights
At the same time provide 粗拆 and 细拆 Two options
Explain the boundaries, risks, and applicable quantity of each option

If the user has not specified a module:

First identify candidate directions in the repository that can be independently filed
Then provide theme combination suggestions according to the quantity requested by the user
If the quantity clearly exceeds the size of the repository, directly reject the unreasonable split

For theme splitting rules and confirmation templates, see references/splitting-rules.md。

3. Confirm the theme or proceed directly to the final draft

If the theme, quantity, and module boundaries are still unclear, first output candidate themes for the user to confirm.

If the user has already clearly provided:

Filing entity
Number of software copyrights
Specified module or clear theme
Repository and page materials sufficient to support writing

Then do not repeat the "candidate theme confirmation" process; proceed directly to the complete final draft.

The confirmation output must include at least:

Theme name
Splitting granularity:粗拆 or 细拆
Theme boundaries
Main function points
Expected screenshot sources
Expected 8-12 screenshot list, preferably 10 screenshots, explaining the function point corresponding to each screenshot
Expected source code scope
Differences from other themes

The software copyright name must end with 系统、平台、软件 or app软件 .

4. Prepare materials and evidence

After the user confirms the themes, then prepare the materials for each theme.

The following hard rules must be checked with emphasis:

When Logo appears, a trademark registration certificate must be required
The 版权所有appearing in document text or screenshots must be exactly consistent with the full name of the copyright owner
Interface screenshots must be actual running software interfaces, and must not be design mockups or renderings
When a domain name appears, the domain name filing query result page must be required
The source code must satisfy the first 1500 lines and the last 1500 lines, totaling no fewer than 3000 lines; if insufficient, provide all source code
Keep source code comments; do not delete comment information
Third-party copyright information must not be retained
The main text must be expanded enough to support " 30 lines per page, about 30 pages, total word count 3w-4w, usually about 3.5w" of filing volume
By default, plan 8-12 interface screenshots for each software copyright, preferably preparing 10 screenshots; unless the product interface is truly insufficient, do not include only 3-5 screenshots
The final main text must not contain GitHub、仓库、repo、README、开源地址、提交记录、分支、clone and other code hosting or code analysis terminology, unless they are unavoidable function names in the software's own interface
The main text should not contain source-related expressions such as "discovered by analyzing the repository," "this repository contains," or "the GitHub page shows"; these belong only to the internal analysis process and are not part of the software copyright product introduction

If the user has not provided ready-made webpage screenshots, preferably run scripts/fetch_web_evidence.py to call a browser to visit the official website, product backend, demo environment, or other actually running pages and generate screenshots. After the screenshots are completed, keep manifest.json, and later when exporting .docx , use --evidence-manifest to automatically insert the screenshots into the main text placeholders. Only when the browser cannot access, the login state is missing, or the page is unreachable, keep it in the main text [此处添加对应图片]。

Before taking screenshots, first do "screenshot planning" and break the current software copyright theme into finer functional perspectives:

Entry/home page or workbench
List, search, filter, or category view
Create, edit, configure, or import entry
Form, wizard, parameter configuration, or upload page
Detail page, preview page, or result page
Status flow, task progress, or processing result
Permissions, members, spaces, logs, or settings page
Data management, statistics, testing, or runtime feedback page
Exception prompts, empty states, or boundary states strongly related to the current theme
Other pages that can prove the functional closed loop of the theme

Each screenshot must correspond to a functional point or business process in the main text; do not repeatedly capture the same page just to make up the number.

For product interface screenshots, you must first determine the login status:

First use Playwright to open the product interface URL provided by the user, and use --ready-text or --wait-selector to determine whether the post-login page has been reached.
If login is detected as required, the user must first complete authorized login in the browser window popped up by Playwright, and then continue to enter the target page for screenshots.
The login state should preferably be saved to browser-profile/ or auth-state.jsonunder the task output directory; do not reuse the user's daily Chrome Profile.
Only if the user explicitly requests "continue without logging in" is it allowed to add --allow-unauthenticated to continue taking screenshots of the current page; in this case, the final materials must note that the screenshots may not be the complete product runtime interface, and if necessary retain [此处添加对应图片]。

5. Generate two types of files for each software copyright

Each software copyright must output two files:

主题内容文件
源码原文文件

Choose the main text template according to the theme volume:

Ordinary single theme: read references/template-standard.md
Platform-type or long-process themes: read references/template-extended.md

For the rules of the source code original text file, see references/source-info-template.md。

The main text file is not a short description; it must be written in one go according to the filing standard to about 30 pages, about 30 lines per page, with a total word count of 3w-4w , usually controlled at around 3.5w .

The main text language must be formal software copyright product description language:

Use expressions such as "this software", "this system", "the platform", and "users can" to introduce functions and processes
Focus on writing product functions, interface operations, business objects, data processing, runtime effects, and technical implementation
A small number of local code snippets may be cited to explain the technical implementation, but do not write source code origins, repository structures, GitHub pages, or README content into the main text
When multiple software copyrights come from the same project, they must also be distinguished by their respective product functional boundaries; directory names or repository module names cannot be used as the main narrative of the main text

Heading levels must strictly progress:

Use ## 1. 标题for first-level main text headings; the number has only one segment
Use ### 1.1 标题for second-level main text headings; the number must include the parent number
Use #### 1.1.1 标题for third-level main text headings; the number must include the parent and second-level numbers
All Markdown headings must be written flush left; there must be no spaces, tabs, or full-width spaces at the beginning of the line
Headings are not allowed to be written into lists, quotes, indented paragraphs, or table cells
3.1 If headings continue to be split below, only 3.1.1、3.1.2、3.1.3can be written, and it cannot jump to 3.2.1 or directly write 3.1 模块目标
Headings at the same level must be numbered consecutively; you cannot jump from 3.1.1 to 3.1.3
Export .docx Before exporting, the heading numbering will be validated, and indented headings will be normalized as a fallback; if the numbering is non-compliant, you must first correct the document and must not force the export

A small number of "local code snippets" may be added to the main text, but only key code directly related to the current topic may be included; do not pad it with large blocks of source code. Prefer placing them in:

Functional module design
Key business process description
Key technical implementation

Do not write explanations, summaries, table of contents descriptions, or risk descriptions in source code files. The layout of source code documents must be organized in the order of "file name -> original code -> file name -> original code".

If the source code scope has already been confirmed, run:

python3 scripts/assemble_source_code.py \
  --path repo/module-a \
  --path repo/module-b \
  --output out/source-code.txt

This script will output according to the rule of "first 1500 lines + last 1500 lines, or the full content if fewer", output the original source code, and segment it by file name.

6. Export `.docx`

After both the main text and the original source code have been generated, if the user needs a formal delivery document, run:

python3 scripts/export_ruanzhu_docx.py --content path/to/topic.md --source path/to/source-code.txt --output out/docx

This script will separately export the main text .docx and the source code .docx two files.

If you have already used fetch_web_evidence.py to generate screenshot evidence, you must pass in manifest.json：

python3 scripts/export_ruanzhu_docx.py \
  --content path/to/topic.md \
  --source path/to/source-code.txt \
  --evidence-manifest out/evidence/manifest.json \
  --output out/docx

when exporting. The export script will follow the screenshot order in manifest.json and replace the [此处添加对应图片] in the main text one by one with the actual images. You can also use --image-dir path/to/screenshots to directly read a certain image directory.

The default export layout uses:

Main text: Chinese 宋体, English and numbers Times New Roman
Main text font size:12pt
Main text line spacing:1.5 倍
Level 1 heading:黑体、16pt, bold
Level 2 heading:黑体、14pt, bold
Level 3 heading:黑体、12pt, bold
Source code document: segmented by file name, with the file name on its own line, and the source code written line by line; in Word, one line of source code corresponds to one line of content

If project screenshots need to be inserted into the main text but screenshots cannot currently be completed, placeholders must be reserved directly:

[此处添加对应图片]

7. Quality check

After generating the results, review item by item:

Whether the name suffix is compliant
Whether multiple topics obviously overlap
Whether the main text matches the screenshots
Whether the main text uses product description wording and does not include internal analysis information such as GitHub, repositories, README, or commit records
Whether the heading numbering strictly progresses and conforms to ## 3. -> ### 3.1 -> #### 3.1.1 hierarchical relationship
版权所有 Whether it is completely consistent
Whether the domain name is supported by filing page evidence
Whether the Logo is supported by a trademark certificate
Whether the main text reaches about 30 pages and the total word count reaches 3w-4w
Whether the local code snippets are strongly related to the current topic and moderate in number
Whether the source code files are original code rather than explanatory documents
Whether the source code document is laid out in segments as "file name -> original code"
Whether the source code scope can be mapped to specific directories and files
Whether third-party copyright information is mistakenly included

If high-risk issues are found, list the issues and correction suggestions first; do not hand in materials that will obviously be rejected as finished products.

Scripts

`scripts/fetch_web_evidence.py`

Use this script to call the browser to visit the page and generate screenshots.

Applicable scenarios:

The user only provided the repository URL and the official website URL, with no accompanying screenshots
Need to supplement the main text with page evidence that has a clear and traceable source
Need to save the page title, URL, and capture time
Need to automatically access the product interface and capture the actual running interface
When the product interface requires login, the Playwright storageState login state can be reused

Public page example:

python3 scripts/fetch_web_evidence.py \
  --url https://github.com/openai/openai-cookbook \
  --url https://openai.com \
  --output out/evidence

Product page example:

python3 scripts/fetch_web_evidence.py \
  --url https://example.com/dashboard \
  --wait-selector "#app" \
  --selector "main" \
  --viewport-width 1440 \
  --viewport-height 1200 \
  --output out/evidence

Example of a product interface that requires login:

python3 scripts/fetch_web_evidence.py \
  --url https://example.com/dashboard \
  --auth-state auth-state.json \
  --ready-text "工作台" \
  --wait-selector "#app" \
  --output out/evidence

When manual login is required, you can first use a visual browser window:

python3 scripts/fetch_web_evidence.py \
  --url https://example.com/dashboard \
  --headed \
  --profile-dir out/browser-profile \
  --ready-text "工作台" \
  --save-auth-state auth-state.json \
  --output out/evidence

Authentication file rules:

--auth-state auth-state.json: reads the Playwright storageState login state file; the file path is specified by the caller.
--save-auth-state auth-state.json: after the screenshot is taken, saves the current login state to the specified JSON file.
--profile-dir out/browser-profile: uses a persistent browser directory; login states such as cookies and localStorage are saved in this directory, suitable for reusing backend logins multiple times.
Do not use the user's daily Chrome Profile as --profile-dir, to avoid polluting the user's browser data.
If using --ready-text and the page has not entered the logged-in state,--headed mode will prompt the user to log in in the pop-up browser and wait for up to --login-timeout-ms. Non- --headed mode will directly report an error and will not screenshot the login page to pass it off as the product interface.
Only when the user explicitly forces continuing without login, add --allow-unauthenticated; this mode will not wait for login and will directly capture the current page.

The script will output:

Screenshot file
manifest.json, used for subsequent automatic insertion into .docx
summary.md

The input file also supports batch page configuration:

首页 | https://example.com/dashboard | main
订单页面 | https://example.com/orders | #app

When you need to click a page menu before taking a screenshot, you can use a JSON configuration:

{
  "pages": [
    {
      "name": "产品资料上传界面",
      "url": "https://example.com/workbench",
      "click_texts": ["资料中心", "产品资料库", "新建/导入", "文本资料"]
    }
  ]
}

Then run:

python3 scripts/fetch_web_evidence.py \
  --input pages.json \
  --profile-dir out/browser-profile \
  --headed \
  --ready-text "工作台" \
  --output out/evidence

--profile-dir will reuse the persistent browser login state, suitable for any product backend, admin console, or SaaS system that requires login. On the first run, you can log in in the pop-up browser, and subsequent runs in the same directory will continue to reuse the login state.

When the user forces continuing without login:

python3 scripts/fetch_web_evidence.py \
  --input pages.json \
  --ready-text "工作台" \
  --allow-unauthenticated \
  --output out/evidence

To avoid accidental operations, the script will not automatically click 确认、提交、删除、保存、支付、创建 and other buttons that may change data. When such actions are needed, first have the user explicitly confirm, and preferably only stay on the interface required for the screenshot.

`scripts/assemble_source_code.py`

Use this script to generate the source code original text file.

Applicable scenarios:

The source code scope corresponding to a certain software copyright topic has already been determined
Need to organize the source code according to software copyright rules
Need to directly output the original code, no summary

Example:

python3 scripts/assemble_source_code.py \
  --path repo/src/module-a \
  --path repo/src/module-b \
  --output out/source-code.txt

Script rules:

Aggregate text source code within the specified path
Preserve original comments
Lay out in the order of file name, source code, file name, source code
When the total number of lines exceeds 3000 , output the first 1500 lines and the last 1500 lines
When the total number of lines is less than 3000 , output all source code
Do not automatically add explanatory text

`scripts/export_ruanzhu_docx.py`

Use this script to export the Markdown draft as .docx。

Applicable scenarios:

The main text and source code original text file have already been generated
Need to deliver a more formal document format

The script requires the local Python environment to have python-docxinstalled. If the default Python is missing packages, you can use SOFTWARE_COPYRIGHT_WRITER_PYTHON Specify another Python interpreter.

The screenshot script requires local Node.js, Playwright, and Chrome/Chromium. By default it uses node, the Node module resolution path, and common browser paths; if the environment differs, you can specify them via SOFTWARE_COPYRIGHT_WRITER_NODE、SOFTWARE_COPYRIGHT_WRITER_NODE_MODULES、SOFTWARE_COPYRIGHT_WRITER_CHROME_PATH .

Dependency installation example:

python3 -m pip install -r scripts/requirements.txt
npm install --prefix scripts
npx --prefix scripts playwright install chromium

References

references/intake-checklist.md: Material collection and hard rule checks
references/splitting-rules.md: Topic splitting rules, naming rules, and confirmation output
references/template-standard.md: Standard edition body template
references/template-extended.md: Extended edition body template
references/source-info-template.md: Source code original text file rules

Output Rules

Default output recommendations:

One body Markdown per software copyright
One source code original text file per software copyright
If web evidence was captured, keep the screenshots and manifest.json
If exporting .docx, export the body and source code separately; do not mix them into one file
When the input information is already complete, the body must be output in full as a finished draft in one go; do not first output an outline, a draft table of contents, or a half-finished draft by chapter
The target total word count of the body must fall within 3w-4w, preferably close to 3.5w
The source code document must be segmented by file name, preserving the source code line by line; it is not allowed to compress it into one large paragraph
When the user explicitly requests 5 copies or another fixed quantity, if the repository and materials are sufficient to support it, directly produce the corresponding number of complete documents consecutively

Keep file naming as stable as possible, for example:

xxx-主题内容.md
xxx-源码原文.txt
xxx-主题内容.docx
xxx-源码原文.docx

Failure Rules

When encountering the following situations, first warn about the risks; do not force the writing:

The number of software copyrights requested by the user is far greater than the number of topics that can be independently split from the repository
The module size specified by the user is too small to reasonably split out multiple topics
There are only design mockups, with no screenshots of the actual running interface
A Logo appears but there is no trademark registration certificate
A domain name appears but there is no filing page
The body word count clearly falls short of 3w or clearly exceeds 4w
The source code file is not original code, but rather a summary or explanatory text
The source code document compresses multiple lines of code into one lump, making it impossible to have one line of source code correspond to one line of document content

In this scenario, you should first give the user a "gap list + correction suggestions + minimum viable scope to continue".

About this skill

Overview

Compliance Boundary

Output Mode

Workflow

1. Collect input

2. Understand the repository and generate candidate topics

3. Confirm the theme or proceed directly to the final draft

4. Prepare materials and evidence

5. Generate two types of files for each software copyright

6. Export .docx

7. Quality check

Scripts

scripts/fetch_web_evidence.py

scripts/assemble_source_code.py

scripts/export_ruanzhu_docx.py

References

Output Rules

Failure Rules

6. Export `.docx`

`scripts/fetch_web_evidence.py`

`scripts/assemble_source_code.py`

`scripts/export_ruanzhu_docx.py`