Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Generate guided Chinese software copyright application materials from a real project. Use this skill when the user asks for 软件著作权, 软著申请资料, 软著代码材料, 操作手册, 申请表信息, or wants Word/TXT materials for software copyright registration. The workflow analyzes the imported project, extracts real source code, creates Markdown drafts for user confirmation, then uses bundled DOCX tooling to produce final Word documents and TXT.
| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-02 | ✗→✓ | ▲ Improved | 262% | 0% |
| case-04 | ✗→✓ | ▲ Improved | 1563% | 0% |
| case-05 | ✗→✓ | ▲ Improved | 186% | 0% |
| case-07 | ✗→✓ | ▲ Improved | 205% | 0% |
| case-08 | ✗→✓ | ▲ Improved | 383% | 0% |
这个 skill 生成可审阅、可追溯的软著申请资料。核心原则：
软件著作权申请资料/。不要默认写到 /tmp、/private/tmp 或其他临时目录。软件著作权申请资料/正式资料/，不要散落在输出目录根部。草稿/申请表信息.md 的“软件全称”字段一致；正式生成时以已确认的申请表软件全称为准。草稿/申请表信息.md 的“版本号”字段一致；正式生成时以已确认的申请表版本号为准。草稿/业务理解.md/json，理解软件业务、行业、目标用户、核心价值和操作流程。草稿/操作手册自检记录.md 和 草稿/操作手册自检记录.json，记录初稿、按项目流程扩写、去制式表达等自检轮次；如果前 3 轮仍发现问题，必须继续补写修正，直到问题清零或记录无法自动修复的原因后再停止。vendor/docx-toolkit；不得引用外部 DOCX 目录。凡是涉及用户选择、确认或补充信息的阶段，必须先停止当前执行，不得继续调用下一步脚本。即使处于自动审核、自动继续或无人值守模式，也必须把 STOP_FOR_USER 和 NEXT_ACTION 原样告知用户，并等待用户输入后再继续。
禁止使用“用户未选择则默认继续”的逻辑。用户回复确认后，先用确认脚本记录对应门禁，再进入下一阶段：
bashpython3 scripts/confirm_stage.py --workdir 软件著作权申请资料 --stage <阶段名> --note "<用户确认内容>"
必须停住的门禁：
environment：完整 DOCX 环境缺失时，用户必须选择“安装完整环境”或“使用基础 DOCX 兜底继续”。project：存在多个项目候选目录时，用户必须指定项目目录。business：草稿/业务理解.md 生成后，用户必须确认行业、目标用户、核心功能和申请口径。application-fields：草稿/申请表信息.md 生成后，用户必须补全并确认硬件、系统环境、著作权人、日期等字段。code-selection：草稿/代码文件选择.json 生成后，用户必须确认或修改抽取文件和行段。screenshot-method：操作手册截图前，用户必须在 Chrome DevTools MCP、Codex Computer Use、用户自行截图三种方式中选择一种；如果用户明确说“现在不截图/先跳过截图”，记录为 skip。markdown：全部 Markdown 草稿完成后，用户必须确认可以进入 Word/TXT 生成。一开始先在当前工作目录创建输出目录并检查运行能力：
bashpython3 scripts/check_environment.py \ --out-dir 软件著作权申请资料
输出：
软件著作权申请资料/环境检查.md软件著作权申请资料/环境检查.json环境检查必须告诉用户：
vendor/docx-toolkit 的完整 OpenXML 环境是否可用。.NET SDK 缺失，询问用户是否安装完整环境。用户选择：
vendor/docx-toolkit/scripts/setup.sh 的要求安装依赖，再继续。完整环境生成和校验更规范。用户回复后记录门禁：
bashpython3 scripts/confirm_stage.py \ --workdir 软件著作权申请资料 \ --stage environment \ --note "<用户选择>"
不要等到最后验证阶段才发现完整 DOCX 环境不可用；这个信息必须在流程开始时给出。
用户通常会把项目放在当前文件夹下。先扫描当前目录，避开本 skill、自身输出目录、node_modules、构建产物和隐藏目录，找到最可能的项目根目录。
如果有多个候选项目，必须停止并询问用户选择；如果只有一个明显候选项目，可以直接使用。
运行：
bashpython3 scripts/analyze_project.py \ --project <项目目录> \ --out 软件著作权申请资料/analysis/project.json
分析内容包括：
package.json、README、脚本命令、依赖在写申请表和操作手册前，先让脚本收集项目证据：
bashpython3 scripts/generate_business_context.py \ --project <项目目录> \ --analysis 软件著作权申请资料/analysis/project.json \ --software-name "<软件全称>" \ --out-dir 软件著作权申请资料/草稿
输出：
草稿/业务理解证据.md草稿/业务理解证据.json草稿/业务理解模型稿模板.json这一步只收集证据，不决定最终业务口径。接下来必须由模型阅读 业务理解证据.md/json、README、PRD/BRD、页面文案、路由、接口、必要源码和用户补充资料，自行判断：
模型不得用脚本关键字表决定行业、功能和结构；不得把用户给的范本文案、测试项目名称、测试项目流程写成通用规则。
模型完成研判后，生成一个业务理解模型稿 JSON，字段至少包含：
product_positioningindustrytarget_userscore_valuebusiness_featuresbusiness_feature_detailsoperation_flowapplication_purposemain_functionstechnical_characteristicsmanual_sections然后运行：
bashpython3 scripts/generate_business_context.py \ --project <项目目录> \ --analysis 软件著作权申请资料/analysis/project.json \ --software-name "<软件全称>" \ --out-dir 软件著作权申请资料/草稿 \ --model-context <模型生成的业务理解JSON>
输出：
草稿/业务理解.md草稿/业务理解.json最终业务理解必须覆盖：
如果项目材料不足、业务类型较新，或用户明确希望参考竞品，可联网搜索相近产品和行业资料；外部调研只用于理解行业表达，不能编造项目不存在的功能。调研摘要应写入业务理解草稿，并区分“项目证据”和“行业参考”。
生成 业务理解.md/json 后必须停止，等待用户确认或修改。业务理解确认前，不得生成申请表和操作手册。如果业务理解仍不充分，先请用户补充产品说明。用户确认后运行：
bashpython3 scripts/confirm_stage.py \ --workdir 软件著作权申请资料 \ --stage business \ --note "<用户确认内容>"
根据分析结果，向用户确认：
项目可推断字段可以先给建议值；硬件/系统环境必须允许用户选择建议值或手动填写。字段口径必须区分清楚：
申请表信息.md 的“软件全称”字段一致。申请表信息.md 的“版本号”字段就是正式资料版本号。此阶段需要先停止等待用户输入；收到用户回复后，可整理为 answers JSON 传入申请表草稿生成。申请表字段的最终门禁在 草稿/申请表信息.md 生成后记录。
生成代码材料前，先运行候选文件分析：
bashpython3 scripts/propose_code_selection.py \ --project <项目目录> \ --analysis 软件著作权申请资料/analysis/project.json \ --out-dir 软件著作权申请资料/草稿
输出：
草稿/代码文件候选清单.md：给用户看的候选说明。草稿/代码文件选择.json：可编辑的选择文件。脚本生成的候选清单只列证据，不默认选择文件。模型必须先阅读业务理解、候选文件、入口文件、页面文件和必要源码，判断哪些源码最能体现软件真实功能和运行逻辑，然后修改 代码文件选择.json：
selected: true 表示抽取该文件。selected: false 表示不抽取该文件。start_line 和 end_line 可用于只抽取某个文件的指定行段。model_reason 必须说明为什么选择该文件或行段。模型选择通常优先考虑前端入口、页面、核心组件、业务交互、数据请求、状态处理等能给审核员看懂软件功能的代码；如果相关前端代码不足 60 页，再补充后端服务、业务处理、配置等相关源码。补充文件同样必须写入 代码文件选择.json 并由用户确认。不要默认抽取全量代码库。用户确认并记录 code-selection 门禁后，代码抽取只读取 代码文件选择.json 中选中的文件和行段。用户确认后运行：
bashpython3 scripts/confirm_stage.py \ --workdir 软件著作权申请资料 \ --stage code-selection \ --note "<用户确认内容>"
运行代码材料抽取：
bashpython3 scripts/extract_code_material.py \ --project <项目目录> \ --analysis 软件著作权申请资料/analysis/project.json \ --selection 软件著作权申请资料/草稿/代码文件选择.json \ --software-name "<软件全称>" \ --version "<版本号>" \ --out-dir 软件著作权申请资料/草稿
代码分页规则：
>= 60：生成 代码-前30页.md 和 代码-后30页.md。< 60 且候选源码已用尽：只生成 代码-全部.md。< 60 但候选清单还有可补充源码：停止并要求用户在 代码文件选择.json 中继续选择补充文件。代码提取清单.md 和 代码提取清单.json，用于追溯代码来源。生成申请表信息草稿：
bashpython3 scripts/generate_application_info.py \ --analysis 软件著作权申请资料/analysis/project.json \ --code-manifest 软件著作权申请资料/草稿/代码提取清单.json \ --business-context 软件著作权申请资料/草稿/业务理解.json \ --software-name "<软件全称>" \ --version "<版本号>" \ --out-dir 软件著作权申请资料/草稿
生成后必须停止，让用户检查并补全 草稿/申请表信息.md。字段补全并确认后运行：
bashpython3 scripts/confirm_stage.py \ --workdir 软件著作权申请资料 \ --stage application-fields \ --note "<用户确认内容>"
生成操作手册草稿：
bashpython3 scripts/generate_manual_draft.py \ --analysis 软件著作权申请资料/analysis/project.json \ --business-context 软件著作权申请资料/草稿/业务理解.json \ --software-name "<软件全称>" \ --version "<版本号>" \ --out-dir 软件著作权申请资料/草稿
操作手册草稿不得强制套用用户提供的范本文案或固定章节。应先基于模型写入 草稿/业务理解.json 的 manual_sections 和项目页面入口，自主组织适合该项目的手册结构；通常需要覆盖软件概述、适用对象、运行环境、进入软件、主要功能、操作流程和注意事项等内容，但章节标题和顺序可以随项目实际调整。各章节应包含段落化说明，功能模块不能只列标题和步骤，必须写清楚模块用途、用户操作和系统反馈。语言要面向审核员和普通读者，说明“这个模块是干嘛的、用户怎么操作、操作后看到什么”，不要写代码实现、框架名称、接口封装、状态管理、异步队列等技术细节。撰写时由 agent 自行检查章节是否完整、内容是否过薄、语言是否过于技术化，并在草稿内部完成必要补写；完整草稿完成后只让用户做一次整体确认，确认前不得进入正式 Word/TXT 生成。
生成脚本必须同时写出 草稿/操作手册自检记录.md 和 草稿/操作手册自检记录.json。自检记录至少包含：
操作手册的模块写作必须从 草稿/业务理解.json 的行业、目标用户、核心价值、业务功能和典型操作流程出发。不同模块要写出各自的业务作用，不能统一套用“进入页面、填写内容、提交按钮、查看结果”的固定句式；相近模块也要结合项目真实业务区分各自的操作目的和结果，不得把测试项目的功能名称、业务流程或示例文案写成通用规则。
操作手册草稿完成后，先停止并让用户选择截图方式，必须给出三种选项：
软件著作权申请资料/用户截图/，agent 只负责整理和引用。如果用户明确说“现在不截图”“先跳过截图”“这次不截图”，也必须记录截图方式门禁，方法填 skip。跳过截图不阻塞正式资料生成，但操作手册中每个核心功能模块必须保留可见的截图预留文字，例如：【截图预留：请在此处插入“项目管理”页面或操作结果截图。】。不要使用 HTML 注释作为截图占位，因为正式 Word 中看不到。
用户选择后，先记录门禁：
bashpython3 scripts/confirm_stage.py \ --workdir 软件著作权申请资料 \ --stage screenshot-method \ --method <chrome-devtools|computer-use|user-supplied|skip> \ --note "<用户选择>"
然后按用户选择检查当前能力并执行：
mcp__chrome_devtools__ 的 list_pages、take_snapshot、take_screenshot。可用时，先 list_pages 确认当前浏览器页面，再按页面/路由截图保存到 软件著作权申请资料/截图/；不可用时停止，告知用户需要重新选择截图方式或手动提供截图。mcp__computer_use__ 的 get_app_state、click、press_key。可用时，先 get_app_state 查看目标应用或浏览器当前状态，再按操作手册需要导航和截图；如果当前 Computer Use 只能返回会话内截图而不能直接保存图片文件，则说明限制，并让用户改选 Chrome DevTools MCP 或把截图放入 用户截图/。软件著作权申请资料/用户截图/，提示用户把截图文件放入该目录；用户放入后运行下面的整理命令，把图片复制到 软件著作权申请资料/截图/ 并生成 截图清单.json。bashpython3 scripts/capture_screenshots.py \ --manual-dir 软件著作权申请资料/用户截图 \ --out-dir 软件著作权申请资料/截图
截图成功后，把截图引用补入 草稿/操作手册.md；截图失败或用户选择暂不提供截图时，继续生成带截图预留位的文字版，并在报告中说明“操作手册截图未生成或未插入，已保留截图预留位置”。
生成 Word 前，必须让用户确认 软件著作权申请资料/草稿/ 下的 Markdown。
重点检查：
申请表信息.md 的“软件全称”一致申请表信息.md 的“版本号”一致业务理解.md 是否准确反映软件真实业务、行业和目标用户申请表信息.md 中“待用户确认”的字段是否已确认用户确认后，必须记录 markdown 门禁；未记录时不得生成正式 Word/TXT。
bashpython3 scripts/confirm_stage.py \ --workdir 软件著作权申请资料 \ --stage markdown \ --note "<用户确认内容>"
用户确认后运行：
bashpython3 scripts/build_docx_from_md.py \ --workdir 软件著作权申请资料 \ --software-name "<软件全称>" \ --version "<版本号>"
正式生成脚本必须重新读取 草稿/申请表信息.md 中已确认的“软件全称”和“版本号”，并用它们生成正式资料文件名、代码 Word 页眉和操作手册 Word。若命令参数 --software-name / --version 与申请表字段不同，以申请表字段为准，并在 正式资料/生成报告.md 中记录提示。
输出：
正式资料/申请表信息.txt正式资料/<软件全称>-代码(前30页).docx正式资料/<软件全称>-代码(后30页).docx正式资料/<软件全称>-代码(全部).docx正式资料/<软件全称>_操作手册.docx正式资料/生成报告.md至少执行三轮验证并修复发现的问题：
业务理解.md 和项目文档。可用命令：
bashpython3 -m py_compile scripts/*.py bash vendor/docx-toolkit/scripts/docx_preview.sh <生成的docx>
完整 DOCX 环境检查和安装必须直接恢复/构建 vendor/docx-toolkit/scripts/dotnet/DocxToolkit.Cli/DocxToolkit.Cli.csproj，不要对 vendor/docx-toolkit/scripts/dotnet 目录或 .slnx 文件执行隐式 restore/build。
如果 环境检查.md 或 vendor/docx-toolkit/scripts/env_check.sh 显示 .NET SDK 缺失，说明完整 DOCX OpenXML 校验环境未就绪。用户明确选择不安装并记录 environment 门禁后，继续生成 Markdown、TXT 和基础 DOCX，并在报告中说明当前使用兜底路径。
以下场景必须询问并停止，等待用户输入后再继续：
代码文件选择.json。Other measured skills in the registry, with their headline benchmark lift.