software-copyright-materials

Software Copyright Application Materials Generation

This skill generates reviewable and traceable software copyright application materials. Core principles:

• Fixed output directory: under the current working directory, 软件著作权申请资料/. Do not write by default to /tmp、/private/tmp or other temporary directories.
• Only when testing the skill itself is it allowed to explicitly specify a temporary directory; when generating materials for users, they must be written to the current directory.
• First generate a Markdown draft, and after the user confirms, generate the formal Word/TXT.
• Formal Word/TXT can only be written to 软件著作权申请资料/正式资料/, and must not be scattered in the root of the output directory.
• The text of the formal Word/TXT must always use the default black font; do not generate blue hyperlinks, theme-colored headings, or other colored text; when Markdown links are written into Word, they must be converted to plain text.
• The software name in the formal materials must be consistent with 草稿/申请表信息.md 's "Software Full Name" field; at the time of formal generation, the confirmed software full name in the application form shall prevail.
• The version number in the header of the formal code Word must be consistent with 草稿/申请表信息.md 's "Version Number" field; at the time of formal generation, the confirmed version number in the application form shall prevail.
• The code materials must come from real project source code; AI is prohibited from fabricating code.
• Before writing the application form and operation manual, you must first form the model-assessed 草稿/业务理解.md/json, to understand the software business, industry, target users, core value, and operation flow.
• Scripts can only collect project evidence, validate fields, and generate files; industry judgment, function extraction, code extraction selection, and operation manual structure must be decided by the model after reading the project, and must not rely on script keyword tables or fixed templates.
• Prioritize extracting frontend code: entry points, routing, pages, core components, API wrappers, state management, and utility functions.
• Before generating code materials, you must first generate a candidate list of code files; after understanding the project, the model fills in the extracted files and selection reasons, and then asks the user to confirm or modify.
• Code should preferentially extract the source code confirmed by the model and the user that best reflects the software's real functions and operating logic; when fewer than 60 pages, supplement from other related source code files to 60 pages; when the candidate source code is still fewer than 60 pages, only then generate the full code document.
• Source code discovery must not rely on a whitelist of programming language extensions. By default, the script scans readable text files and excludes explicit documents, configurations, media, archives, binaries, generated artifacts, and oversized files; source code with unknown extensions also enters the candidate list, and then the model and the user confirm whether to extract it.
• Business evidence collection must discover textual design materials as well as DOCX, PDF, ODT, DOC, WPS, and other documents in the project; when the main text can be automatically extracted, write it into the evidence; when it cannot be extracted, the path must still be registered and the model prompted to read further, and it must not be silently omitted because the format is not in the text extension list.
• The final operation manual should read like the operating instructions accompanying real software, not a development description, feature list, or AI-generated summary document.
• The operation manual draft must be organized according to the traditional software copyright operation manual skeleton: related documents, description, feature characteristics, system requirements, chapter-by-chapter operations based on real pages/flows, FAQ, and glossary. First-level chapter titles use uppercase Chinese numerals, for example 一、相关文档, and must not use (1)、相关文档. Related documents must use a table to point to supporting documents such as the overall design, detailed design, and test cases. The main text should use continuous paragraphs as much as possible, and should not use bulleted lists or 1. 2. 3. numbered lists.
• Each core page must explain, from the perspective of an ordinary user, the page purpose, entry location, visible content, user actions, input restrictions or exception prompts, result feedback, and screenshot placeholder. Do not write the section as a field template such as "Entry method: / Page content: / Operation steps: / Operation rules: / Operation results and feedback:"; this information should be naturally merged into paragraphs. Avoid technical expressions such as code, frameworks, interfaces, state management, and asynchronous tasks; during writing, the agent should loop through checks, expansions, and corrections on its own, and after the complete draft is finished, initiate only one overall confirmation with the user.
• The operation manual must remove any obvious "AI flavor": avoid empty praise, marketing slogans, all-purpose sentence patterns, the same structure in every chapter, fixed structures at the beginning, middle, and end, overly symmetrical parallelism, correct nonsense without project details, and frequent use of cliches such as "aims to, empowers, one-stop, intelligent, efficient and convenient, significantly improves, powerful capabilities, rich functions." Each paragraph should be able to answer "what this function specifically does in this project, what the user sees, and what result occurs after the operation."
• Operation manual generation must simultaneously output 草稿/操作手册自检记录.md and 草稿/操作手册自检记录.json, recording self-check rounds such as the initial draft, expansion according to the project process, and removal of formulaic expressions; if problems are still found in the first 3 rounds, writing and correction must continue until the problems are cleared or the reason why they cannot be automatically fixed is recorded before stopping.
• For the screenshot method, only user choices are allowed: automatic screenshots via Playwright CLI or screenshots taken by the user. After the user chooses automatic screenshots, first check whether the fixed verified version of playwright-cli is available; if the user says not to take screenshots now, to skip screenshots for now, or if screenshots fail, the operation manual must still retain clearly visible screenshot placeholders, and they must also be visible in the formal Word document.
• The hardware/system environment in the application form information must be confirmed or filled in by the user, and must not be hard-coded.
• Word generation uniformly uses the OfficeCLI backend; Python is only responsible for business analysis, code extraction, gating, and command orchestration, and does not directly unpack, repack, or write DOCX packages. After OfficeCLI finishes writing the main text, it must use /theme + raw-set to unify the theme fonts as SimSun and Times New Roman, and re-read the theme to confirm that default theme fonts such as Calibri, Calibri Light, and DengXian have disappeared.
• The fixed verified version of OfficeCLI is 1.0.151, and at runtime OFFICECLI_SKIP_UPDATE=1must be set; silent upgrades, silent installations, or fallback to python-docx/Pandoc/.NET toolkits are not allowed.
• For details on OfficeCLI installation, batch processing, pagination, and validation, see references/officecli_backend.md。

Paths and On-Demand References

Before starting execution, obtain the absolute directory of this skill from the currently loaded SKILL.md location, recorded as <SKILL_DIR>; find an available Python 3.10+ interpreter, recorded as <PYTHON>. The angle brackets in the commands below are placeholders that must be replaced; do not rely on ${CLAUDE_SKILL_DIR} or any other agent-specific environment variable, and do not hand the placeholders to the shell as-is.

Read the corresponding reference materials according to the current stage, and do not cram all content into the context at once:

• Before filling out the application form, read application_fields.md。
• Before analyzing the business, read business_understanding_rules.md。
• Before selecting and extracting code, read code_selection_rules.md and copyright_material_rules.md。
• Before writing the operation manual, read manual_structure.md。
• After the user chooses automatic screenshots, read playwright_cli_screenshots.md。
• Before formally generating and validating DOCX, read officecli_backend.md。

Mandatory Manual Gatekeeping

For any stage involving user selection, confirmation, or supplementary information, you must first stop the current execution and must not continue to invoke the next step's script. Even in automatic review, automatic continuation, or unattended mode, you must inform the user of STOP_FOR_USER and NEXT_ACTION exactly as they are, and wait for user input before continuing.

The logic of "if the user makes no selection, continue by default" is prohibited. After the user replies with confirmation, first use the confirmation script to record the corresponding gate, then proceed to the next stage:

<PYTHON> "<SKILL_DIR>/scripts/confirm_stage.py" --workdir 软件著作权申请资料 --stage <阶段名> --note "<用户确认内容>"

Gates that must stop:

• environment: When OfficeCLI is missing, the user must confirm a global installation and restart Codex after installation; when the version does not match, the user must switch to the fixed version or explicitly accept the risk of using an unverified version.
• project: When multiple candidate project directories exist, the user must specify the project directory.
• business：草稿/业务理解.md After generation, the user must confirm the industry, target users, core functions, and application scope.
• application-fields：草稿/申请表信息.md After generation, the user must complete and confirm fields such as hardware, system environment, copyright owner, and date.
• code-selection：草稿/代码文件选择.json After generation, the user must confirm or modify the extracted files.
• screenshot-method: Before taking screenshots for the operation manual, the user must choose one of two methods: automatic screenshots via Playwright CLI, or taking screenshots themselves; if the user explicitly says "do not take screenshots now/skip screenshots for now", record it as skip。
• markdown: After all Markdown drafts are complete, the user must confirm that Word/TXT generation can proceed.

Workflow

1. Startup Environment Check

At the very beginning, first create the output directory in the current working directory and check runtime capabilities:

<PYTHON> "<SKILL_DIR>/scripts/check_environment.py" \
  --out-dir 软件著作权申请资料

Output:

• 软件著作权申请资料/环境检查.md
• 软件著作权申请资料/环境检查.json

The environment check must tell the user:

• Materials will currently be generated under "current directory/software copyright application materials".
• Whether Markdown drafts, TXT, OfficeCLI DOCX, OpenXML validation, and preview are available.
• The current OfficeCLI path and version, and whether it equals the fixed verified version 1.0.151。
• If OfficeCLI is missing, ask the user whether to use the official command for a global installation; do not download it to the project directory or skill directory, and do not install silently.
• If the official global installation has been completed but the current process does not yet recognize it, you must require the user to restart Codex, stop the current execution, and rerun the environment check after restart.

User selection:

• If the user is willing to install, run irm https://raw.githubusercontent.com/iOfficeAI/OfficeCLI/main/install.ps1 | iexin Windows PowerShell. After installation is complete, require the user to restart Codex; do not assume in the current task that PATH has refreshed and continue execution.
• After restart, first run officecli --version, then rerun the environment check. Use only the global command in PATH, not OFFICECLI_PATH、--officecli or the in-project 工具/officecli.exe。
• If the user insists on using another version, you must first record the environment gate, and explicitly pass --allow-untested-officecli。
• When no usable OfficeCLI is available, you may only continue generating/modifying Markdown drafts and TXT, and must not generate a DOCX that falsely appears successful.

After the user replies, record the gate:

<PYTHON> "<SKILL_DIR>/scripts/confirm_stage.py" \
  --workdir 软件著作权申请资料 \
  --stage environment \
  --note "<用户选择>"

Do not wait until the final validation stage to discover that OfficeCLI is unavailable; this information must be provided at the start of the process.

2. Locate the Project

Users usually place the project under the current folder. First scan the current directory, avoiding this skill, its own output directory,node_modules, build artifacts, and hidden directories, to find the most likely project root directory.

If there are multiple candidate projects, you must stop and ask the user to choose; if there is only one obvious candidate project, you can use it directly.

3. Analyze the project

Run:

<PYTHON> "<SKILL_DIR>/scripts/analyze_project.py" \
  --project <项目目录> \
  --out 软件著作权申请资料/analysis/project.json

The analysis includes:

• package.json, README, script commands, dependencies
• Frontend framework and main programming languages
• Entry files, routes, pages, components, APIs, state management
• Number of source files and lines of source code
• Candidate software names, candidate main functions, candidate run commands

4. Form a business understanding

Before writing the application form and the operation manual, first let the script collect project evidence:

<PYTHON> "<SKILL_DIR>/scripts/generate_business_context.py" \
  --project <项目目录> \
  --analysis 软件著作权申请资料/analysis/project.json \
  --software-name "<软件全称>" \
  --out-dir 软件著作权申请资料/草稿

Output:

• 草稿/业务理解证据.md
• 草稿/业务理解证据.json
• 草稿/业务理解模型稿模板.json

This step only collects evidence and does not determine the final business definitions. Next, the model must read 业务理解证据.md/json, README, PRD/BRD, page copy, routes, APIs, necessary source code, and user-supplied materials, and judge on its own:

• Which documents and source code should be read with priority
• What industry / domain the software belongs to
• Who the target users are
• What the core value is
• Which functions should be written into the software copyright application materials
• How the typical operation flow should be organized
• What chapter structure is suitable for the operation manual
• How the recommended definitions in the application form should be expressed

The model must not use script keyword tables to determine industry, functions, and structure; it must not write the user-provided template copy, test project names, or test project flows as general rules.

After the model completes its assessment, generate a business understanding model draft JSON whose fields at least include:

• product_positioning
• industry
• target_users
• core_value
• business_features
• business_feature_details
• operation_flow
• application_purpose
• main_functions
• technical_characteristics
• manual_sections
• manual_modules
• system_requirements
• faq
• glossary

Among them, manual_modules is the core input of the operation manual and must be filled in according to the real pages, navigation entries, or business flows. The script must not automatically fill in entries, steps, or feedback according to classification templates such as auth/query/form ; when manual_modules or key fields are missing, it must stop and have the model go back to the project evidence to fill them in. Each module must include:

• title: Page or flow name.
• evidence: Corresponding page, route, component, requirements document, or README evidence.
• purpose: The purpose of that page in the software.
• usage or usage_scenario: Under what business scenario the user will use that page, and what specific matter they are handling. If missing, the operation manual must not be generated.
• entry: Where the user enters that page from.
• visible_elements: The input boxes, buttons, lists, labels, statuses, or result areas that the user can actually see.
• operation_steps: Write the user actions in the order of the real page; do not write code implementation.
• validation_rules: Rules such as required fields, length limits, permissions, quotas, statuses, and exception prompts; if none, leave an empty array.
• feedback: The results, prompts, or status changes the user can see after the operation is completed.
• screenshot: Screenshot placeholder description.

manual_sections Only supplement the purpose, business scenarios, page organization, or user flows of the current software itself; do not write meta-discourse that explains how the document is written, such as "This operation manual is used for...", "For software copyright review...", or "Does not describe code implementation...". The final operation manual should read like a real software manual, not an explanation of the generation process.

Then run:

<PYTHON> "<SKILL_DIR>/scripts/generate_business_context.py" \
  --project <项目目录> \
  --analysis 软件著作权申请资料/analysis/project.json \
  --software-name "<软件全称>" \
  --out-dir 软件著作权申请资料/草稿 \
  --model-context <模型生成的业务理解JSON>

Output:

• 草稿/业务理解.md
• 草稿/业务理解.json

The final business understanding must cover:

• Product positioning
• Target domain / industry
• Target users
• Core value
• Main business functions
• Typical operation flow
• Recommended Application Form Wording
• Evidence Sources
• Recommended Operation Manual Structure

If the project materials are insufficient, the business type is relatively new, or the user explicitly wants to refer to competitors, you may search online for similar products and industry materials; external research is only used to understand industry expressions and must not fabricate features that do not exist in the project. The research summary should be written into the business understanding draft, and a distinction should be made between "project evidence" and "industry reference".

Generate 业务理解.md/json and then you must stop and wait for the user to confirm or modify. Before the business understanding is confirmed, the application form and operation manual must not be generated. If the business understanding is still insufficient, first ask the user to supplement the product description. After the user confirms, run:

<PYTHON> "<SKILL_DIR>/scripts/confirm_stage.py" \
  --workdir 软件著作权申请资料 \
  --stage business \
  --note "<用户确认内容>"

5. Guide the user to confirm the fields

First read application_fields.md, and confirm with the user strictly according to the official website field order, enumerations, lengths, and source wording in it. Suggested values may be given first for fields that can be inferred from the project, but the copyright owner, date, full software name, version number, and hardware/system environment must be explicitly confirmed by the user; when the project version is lower than V1.0, ask whether to use V1.0 this time or the project's current version.

Special notes:

• The full software name and version number are ultimately subject to 草稿/申请表信息.md , and should be used consistently in file names, headers, titles, and body text.
• The source code volume is the total number of lines of all source code of the registered software, not the number of lines of the selected code materials.
• The page count is the number of pages of the code identification materials actually submitted; for the first and last 30 pages mode, enter 60, and when there are fewer than 60 pages, enter the total number of material pages.
• For the software development environment/development tools, do not write technology stacks such as React, Vite, or TypeScript; for field formats and character limits, see the reference document.

At this stage, stop first and wait for user input; after receiving a reply, it may be organized into answers JSON and passed in to generate the application form draft. The final gate for application form fields is recorded after 草稿/申请表信息.md is generated.

6. Confirm code file selection

Before generating code materials, first run candidate file analysis:

<PYTHON> "<SKILL_DIR>/scripts/propose_code_selection.py" \
  --project <项目目录> \
  --analysis 软件著作权申请资料/analysis/project.json \
  --out-dir 软件著作权申请资料/草稿

Output:

• 草稿/代码文件候选清单.md: candidate explanation for the user to view.
• 草稿/代码文件选择.json: an editable selection file.

The candidate list generated by the script only lists evidence and does not select files by default. The model must first read the business understanding, candidate files, entry files, page files, and necessary source code, determine which source code best reflects the software's real functions and operating logic, and then modify 代码文件选择.json：

• selected: true indicates that the file should be extracted.
• selected: false indicates that the file should not be extracted.
• model_reason It must explain why the file is selected.

Model selection usually prioritizes frontend entry points, pages, core components, business interactions, data requests, state handling, and other code that allows reviewers to understand the software's functions; if the relevant frontend code is fewer than 60 pages, then supplement with related source code such as backend services and business processing. Supplementary files must also be written into 代码文件选择.json and confirmed by the user. Do not extract the entire codebase by default. Code materials are extracted as complete files and pure blank lines are removed; extracting only a middle line segment of a file is not supported. After the user confirms and records the code-selection gate, code extraction only reads the complete files selected in 代码文件选择.json . After the user confirms, run:

<PYTHON> "<SKILL_DIR>/scripts/confirm_stage.py" \
  --workdir 软件著作权申请资料 \
  --stage code-selection \
  --note "<用户确认内容>"

7. Generate the Markdown draft

Run code material extraction:

<PYTHON> "<SKILL_DIR>/scripts/extract_code_material.py" \
  --project <项目目录> \
  --analysis 软件著作权申请资料/analysis/project.json \
  --selection 软件著作权申请资料/草稿/代码文件选择.json \
  --software-name "<软件全称>" \
  --version "<版本号>" \
  --out-dir 软件著作权申请资料/草稿

Code pagination rules:

• The code body uses 8pt font size and 13pt fixed line spacing; source lines are first pre-wrapped at a maximum of 90 display columns, and the default material amount is estimated at about 55 physical lines per page, to meet the requirement of no fewer than 50 lines per page. Markdown page grouping is not equal to the hard page break boundaries of the final DOCX; after generation, the actual page count must be re-read by OfficeCLI/Word.
• In the formal DOCX, all code paragraphs are written continuously, with no manual page breaks inserted, and Word automatically paginates according to the A4 page, margins, font, and line spacing.
• Total pages >= 60: generate 代码-前30页.md and 代码-后30页.md。
• Total pages < 60 and the candidate source code has been exhausted: generate only 代码-全部.md。
• Total pages < 60 but the candidate list still has source code that can be added: stop and require the user to continue selecting supplementary files in 代码文件选择.json .
• Do not generate an oversized "full backup Word" for a large project.
• Generate both 代码提取清单.md and 代码提取清单.json, used to trace code sources.
• Each re-extraction will clean up old files in the three types of code Markdown that conflict with the current output mode; subsequent steps may only read 代码提取清单.json of outputs, and must not generate extra material because old files remain in the directory.

Generate the application form information draft:

<PYTHON> "<SKILL_DIR>/scripts/generate_application_info.py" \
  --analysis 软件著作权申请资料/analysis/project.json \
  --code-manifest 软件著作权申请资料/草稿/代码提取清单.json \
  --business-context 软件著作权申请资料/草稿/业务理解.json \
  --software-name "<软件全称>" \
  --version "<版本号>" \
  --out-dir 软件著作权申请资料/草稿

After generation, it must stop and let the user check and complete 草稿/申请表信息.md. After the fields are completed and confirmed, run:

<PYTHON> "<SKILL_DIR>/scripts/confirm_stage.py" \
  --workdir 软件著作权申请资料 \
  --stage application-fields \
  --note "<用户确认内容>"

Generate the operation manual draft:

<PYTHON> "<SKILL_DIR>/scripts/generate_manual_draft.py" \
  --analysis 软件著作权申请资料/analysis/project.json \
  --business-context 软件著作权申请资料/草稿/业务理解.json \
  --software-name "<软件全称>" \
  --version "<版本号>" \
  --out-dir 软件著作权申请资料/草稿

The operation manual draft must not copy the template text or old project content provided by the user, but should absorb their structural characteristics: first write related documents, descriptions, functional features, and system requirements, then explain operations chapter by chapter according to the real pages or core processes, and finally write the FAQ and glossary. First-level chapter titles use Chinese uppercase numerals; the related documents chapter must be a table; the functional features and page operation chapters must be developed in paragraphs, not using bullet points and numbered lists to pile up information. Chapters must be organized based on the model's writing into 草稿/业务理解.json of manual_modules ;manual_sections is only used for supplementary explanatory paragraphs and should not be used to repeatedly insert the same batch of functional modules. Each functional chapter must clearly state the page purpose, entry location, the controls and data the user sees, actual operations, input restrictions or exception prompts, operation results, and screenshot placeholders. The language should be oriented toward ordinary users, explaining "what this page is for, how the user enters, what the user clicks/fills in, and what is seen after the operation," and should not write technical details such as code implementation, framework names, interface encapsulation, state management, or asynchronous queues. During writing, the agent should self-check whether the chapters are complete, whether the content is too thin, and whether the language is too technical, and complete the necessary supplementary writing within the draft; after the complete draft is finished, have the user perform only one overall confirmation, and do not proceed to formal Word/TXT generation before confirmation.

The generation script must write both 草稿/操作手册自检记录.md and 草稿/操作手册自检记录.json. The self-check record must include at least:

• Round 1: first draft generation, checking chapter completeness, screenshot placeholders, module content thickness, and technical expression.
• Round 2: expand the module descriptions according to the project's real operating process, and supplement the upstream and downstream connection relationships.
• Round 3: remove formulaic expressions and AI flavor, with emphasis on checking repeated sentence patterns, unified clichés, vague praise, marketing slogans, overly neat parallelism, and correct nonsense without project details.
• Subsequent rounds: if problems remain, continue supplementing, deduplicating, and rewriting; do not hand uncorrected problems directly to the user.

The module writing of the operation manual must start from 草稿/业务理解.json industry, target users, core value, business functions, typical operation processes and manual_modules Start from this. Different modules must each describe their own business role, entry point, controls, rules and feedback; they must not uniformly apply the fixed sentence pattern of "enter the page, fill in content, click the submit button, view the result," nor use field headings such as "Entry method: / Page content: / Operation steps: / Operation rules: / Operation results and feedback:"; similar modules must also be distinguished by their respective operation purposes and results based on the project's real business. During self-check, you must check whether the same batch of modules is repeatedly expanded in multiple chapters; if duplication is found, change it so that each real page or process becomes its own independent chapter. Do not write the test project's feature names, business processes or sample copy as general rules.

8. Select and obtain screenshots

After the operation manual draft is completed, first stop and let the user choose the screenshot method; two options must be provided:

1. Playwright CLI automatic screenshots: the agent starts or connects to the Web project, controls the browser according to real pages and operation processes, and saves PNG screenshots directly to 软件著作权申请资料/截图原始/。
2. User takes screenshots themselves: the user places PNG/JPG/JPEG/WebP images into 软件著作权申请资料/用户截图/, and the agent is only responsible for organizing and referencing them.

If the user explicitly says "do not take screenshots now," "skip screenshots for now," or "do not take screenshots this time," the screenshot method gate must still be recorded, with the method filled in as skip. Skipping screenshots does not block formal material generation, but each core functional module in the operation manual must retain visible screenshot placeholder text, for example:【截图预留：请在此处插入“项目管理”页面或操作结果截图。】. Do not use HTML comments as screenshot placeholders, because they are not visible in the formal Word document.

After the user chooses, first record the gate:

<PYTHON> "<SKILL_DIR>/scripts/confirm_stage.py" \
  --workdir 软件著作权申请资料 \
  --stage screenshot-method \
  --method <playwright-cli|user-supplied|skip> \
  --note "<用户选择>"

Then check the current capability according to the user's choice and execute:

• Choose Playwright CLI automatic screenshots: you must first read playwright_cli_screenshots.md, run the general global command check script in it, and execute according to the returned absolute path of the executable file, installation gate, fixed version, background service, naming, browser session and disk-write verification rules. You must not require restarting Codex just because the bare command is not in PATH, and you must not use a browser tool that can only display screenshots in the session to pretend success; every screenshot must be a readable and non-empty local image file under 截图原始/ .
• Choose user-taken screenshots: create 软件著作权申请资料/用户截图/, and prompt the user to place screenshot files into that directory; after the user adds numeric prefixes to the file names in the order of the operation manual modules, run the following organizing command to copy the images to 软件著作权申请资料/截图/ and generate an ordered 截图清单.json. Numeric prefixes are sorted by numeric value, so 2-主页.png will be placed before 10-设置.png .
• Choose to skip screenshots: do not run the screenshot tool, continue to retain the visible screenshot placeholder text in the operation manual; in the generation report, state that the user chose not to take screenshots for now, and that the formal operation manual has reserved screenshot positions.

After the screenshot files are ready, the organizing script must be run to generate the 截图/截图清单.jsonthat the formal build will read. Playwright CLI automatic screenshots point --input-dir to 截图原始/、--method set to playwright-cli; user-taken screenshots point to 用户截图/：

<PYTHON> "<SKILL_DIR>/scripts/capture_screenshots.py" \
  --input-dir 软件著作权申请资料/用户截图 \
  --out-dir 软件著作权申请资料/截图 \
  --method user-supplied

After successful screenshots, there is no need to manually modify 草稿/操作手册.md: the formal generation script will, according to the order in 截图清单.json , replace the visible screenshot placeholder positions in the operation manual with the available images in sequence, and then use OfficeCLI picture elements are written into Word. When there are fewer images than reserved slots, keep the unmatched prompts; when there are more images than reserved slots, files are missing, or the format is unsupported, explain this in the generation report. If screenshot capture fails or the user chooses not to provide screenshots for now, continue generating the text version with reserved screenshot slots.

9. User confirms Markdown

Before generating Word, the user must confirm the 软件著作权申请资料/草稿/ Markdown under.

Key checks:

• Whether the software name and version number are consistent
• Whether the software name in the headers of the first 30 pages and last 30 pages of the code material matches the "full software name" in 申请表信息.md .
• Whether the version number in the headers of the first 30 pages and last 30 pages of the code material matches the "version number" in 申请表信息.md .
• Whether the Word header of the operation manual matches the header of the code material, both using 申请表信息.md 's "full software name" and "version number".
• 业务理解.md Whether it accurately reflects the software's real business, industry, and target users.
• 申请表信息.md Whether the fields marked "pending user confirmation" in have been confirmed.
• Whether the code material comes only from complete files confirmed by the user.
• Whether the operation manual fits the reviewer's reading scenario, and whether ordinary readers can understand module purposes and operation methods.
• Whether each chapter of the operation manual has paragraph content, whether core modules clearly describe module purpose, operation process, and result feedback, and whether overly technical language is avoided.
• Whether the screenshots are correct; if the user skips screenshots, whether the formal operation manual retains visible reserved screenshot positions.

After user confirmation, must record markdown gate; if not recorded, the formal Word/TXT must not be generated.

The confirmation script records content fingerprints for business understanding, code selection, application form, and final draft. If any confirmed file is modified after confirmation, the corresponding gate immediately becomes invalid, and the user must be asked to review the changes and reconfirm; the old confirmation boolean cannot be reused. Before final confirmation, it must also be checked that the code extraction list, current code Markdown, application form, operation manual, and operation manual self-check record all exist, and that there is no old draft conflicting with the current code output mode.

<PYTHON> "<SKILL_DIR>/scripts/confirm_stage.py" \
  --workdir 软件著作权申请资料 \
  --stage markdown \
  --note "<用户确认内容>"

10. Generate formal Word/TXT

After user confirmation, run:

<PYTHON> "<SKILL_DIR>/scripts/build_docx_from_md.py" \
  --workdir 软件著作权申请资料 \
  --software-name "<软件全称>" \
  --version "<版本号>"

The formal generation script must reread the confirmed "full software name" and "version number" in 草稿/申请表信息.md and use them to generate the formal document filenames, code Word headers, and operation manual Word headers. The operation manual header must match the code material header format: on the left, "full software name version number"; on the right, "Page <page number>". If the command parameter --software-name / --version differs from the application form field, the application form field prevails, and record the prompt in 正式资料/生成报告.md .

The generation script writes DOCX through OfficeCLI atomic batch, and disables automatic updates and background resident. Each physical line in the code draft corresponds to one Word paragraph; source code lines exceeding 90 display columns are deterministically wrapped during the extraction stage, avoiding page count drift caused by Word wrapping again due to code width. All code paragraphs are written continuously into the body, without setting pageBreakBefore; final pagination is automatically completed by the Word layout engine; page grouping in the draft is only used for material selection amount estimation. Do not enable Word automatic line numbering to replace source code line handling.

Formal generation only processes 草稿/代码提取清单.json the code Markdown declared in outputs , and cleans up old code DOCX under the current software name that conflicts with this mode. It must not traverse the directory and output the first 30 pages, last 30 pages, and all code old files together.

Output:

• 正式资料/申请表信息.txt
• Code reaches or exceeds 60 pages:
  • 正式资料/<软件全称>-代码(前30页).docx
  • 正式资料/<软件全称>-代码(后30页).docx
• Code is less than 60 pages:
  • 正式资料/<软件全称>-代码(全部).docx
• 正式资料/<软件全称>_操作手册.docx
• 正式资料/生成报告.md

11. Three-round verification

Execute at least three rounds of verification and fix the issues found:

1. File integrity: whether the target Word/TXT exists and is non-empty.
2. Code authenticity: sampled code snippets can be traced back to the project source code.
3. Business authenticity: the industry, target users, main functions, and operation flow in the application form and operation manual can be traced back to 业务理解.md and the project documents.
4. Consistency and formatting: whether the software name, version number, page count rules, application form fields, operation manual title, and screenshot references are consistent.

Available commands:

<PYTHON> -m compileall -q "<SKILL_DIR>/scripts"
officecli validate <生成的docx> --json
officecli view <生成的docx> issues --json
officecli view <生成的代码docx> stats --page-count --json
officecli view <生成的docx> screenshot --grid auto --render auto -o <预览.png>

validate only proves that the OpenXML structure is readable; it cannot prove that pagination is correct. On Windows with Word installed, OfficeCLI uses stats --page-count to read the real page count after automatic pagination; the first 30 pages/last 30 pages documents must each be exactly 30 pages, otherwise generation fails and the material selection amount must be recalibrated; do not revert to manually fixed pagination. In other environments, first use OfficeCLI HTML preview, then open the final file in Word/WPS to recheck the page count. Use only the OfficeCLI backend; do not introduce other DOCX rendering dependencies.

When to ask the user

In the following scenarios, you must ask and stop, and continue only after the user provides input:

• Multiple candidate project directories need to be selected.
• When the startup environment check finds that OfficeCLI is missing, ask the user whether to install it globally; after installation is complete, require restarting Codex and stop, then continue after restart. When the version does not match, ask whether to switch to the pinned version.
• After the business understanding draft is generated, ask the user to confirm the software purpose, industry, target users, core functions, and application positioning.
• Registration fields such as the full software name, copyright owner, date, and hardware/system environment need to be confirmed.
• After the candidate code file list is generated, the user needs to confirm or modify 代码文件选择.json。
• Before taking screenshots for the operation manual, the user needs to choose one of two methods: automatic screenshots via Playwright CLI or taking screenshots manually; after choosing automatic screenshots, check again whether the pinned verification version is available.
• Whether the user confirms the Markdown draft and proceeds to Word generation.