software-copyright skill

软著申请资料生成

这个 skill 生成可审阅、可追溯的软著申请资料。核心原则：

• 固定输出目录：当前工作目录下的 软件著作权申请资料/。不要默认写到 /tmp、/private/tmp 或其他临时目录。
• 只有测试 skill 自身时才允许显式指定临时目录；面向用户生成材料时必须写入当前目录。
• 先生成 Markdown 草稿，用户确认后再生成正式 Word/TXT。
• 正式 Word/TXT 只能写入 软件著作权申请资料/正式资料/，不要散落在输出目录根部。
• 正式 Word/TXT 的文字一律使用默认黑色字体，不生成蓝色超链接、主题色标题或其他彩色文字；Markdown 链接写入 Word 时必须转成普通文本。
• 正式资料中的软件名称必须与 草稿/申请表信息.md 的“软件全称”字段一致；正式生成时以已确认的申请表软件全称为准。
• 正式代码 Word 页眉中的版本号必须与 草稿/申请表信息.md 的“版本号”字段一致；正式生成时以已确认的申请表版本号为准。
• 代码材料必须来自真实项目源码，禁止 AI 编造代码。
• 写申请表和操作手册前，必须先形成模型研判后的 草稿/业务理解.md/json，理解软件业务、行业、目标用户、核心价值和操作流程。
• 脚本只能收集项目证据、校验字段和生成文件；行业判断、功能抽取、代码抽取选择、操作手册结构必须由模型阅读项目后决定，不得依赖脚本关键字表或固定范本。
• 优先抽取前端代码：入口、路由、页面、核心组件、接口封装、状态管理、工具函数。
• 生成代码材料前，必须先生成代码文件候选清单；模型理解项目后填写抽取文件、行段和选择理由，再让用户确认或修改。

强制人工门禁

凡是涉及用户选择、确认或补充信息的阶段，必须先停止当前执行，不得继续调用下一步脚本。即使处于自动审核、自动继续或无人值守模式，也必须把 STOPFORUSER 和 NEXT_ACTION 原样告知用户，并等待用户输入后再继续。

禁止使用“用户未选择则默认继续”的逻辑。用户回复确认后，先用确认脚本记录对应门禁，再进入下一阶段：

python3 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 生成。

工作流

1. 启动环境检查

一开始先在当前工作目录创建输出目录并检查运行能力：

python3 scripts/check_environment.py \
  --out-dir 软件著作权申请资料

输出：

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

环境检查必须告诉用户：

• 当前会在“当前目录/软件著作权申请资料”下生成材料。
• Markdown 草稿、TXT、基础 DOCX 是否可用。
• 内置 vendor/docx-toolkit 的完整 OpenXML 环境是否可用。
• 如 .NET SDK 缺失，询问用户是否安装完整环境。

用户选择：

• 如果用户愿意安装完整环境，按 vendor/docx-toolkit/scripts/setup.sh 的要求安装依赖，再继续。完整环境生成和校验更规范。
• 如果用户不安装，继续使用兜底方案生成 Markdown、TXT 和基础 DOCX。
• 如果完整 DOCX 环境缺失，必须停止并等待用户选择；不得自动继续。

用户回复后记录门禁：

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

不要等到最后验证阶段才发现完整 DOCX 环境不可用；这个信息必须在流程开始时给出。

2. 定位项目

用户通常会把项目放在当前文件夹下。先扫描当前目录，避开本 skill、自身输出目录、node_modules、构建产物和隐藏目录，找到最可能的项目根目录。

如果有多个候选项目，必须停止并询问用户选择；如果只有一个明显候选项目，可以直接使用。

3. 分析项目

运行：

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

分析内容包括：

• package.json、README、脚本命令、依赖
• 前端框架和主要编程语言
• 入口文件、路由、页面、组件、接口、状态管理
• 源码文件数量和源程序行数
• 软件名称候选、主要功能候选、运行命令候选

4. 形成业务理解

在写申请表和操作手册前，先让脚本收集项目证据：

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

输出：

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

这一步只收集证据，不决定最终业务口径。接下来必须由模型阅读 业务理解证据.md/json、README、PRD/BRD、页面文案、路由、接口、必要源码和用户补充资料，自行判断：

• 应该重点读取哪些文档和源码
• 软件属于什么行业 / 领域
• 目标用户是谁
• 核心价值是什么
• 哪些功能应写入软著申请资料
• 典型操作流程如何组织
• 操作手册适合采用什么章节结构
• 申请表建议口径如何表达

模型不得用脚本关键字表决定行业、功能和结构；不得把用户给的范本文案、测试项目名称、测试项目流程写成通用规则。

模型完成研判后，生成一个业务理解模型稿 JSON，字段至少包含：

• product_positioning
• industry
• target_users
• core_value
• business_features
• businessfeaturedetails
• operation_flow
• application_purpose
• main_functions
• technical_characteristics
• manual_sections

然后运行：

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

输出：

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

最终业务理解必须覆盖：

• 产品定位
• 面向领域 / 行业
• 目标用户
• 核心价值
• 主要业务功能
• 典型操作流程
• 申请表建议口径
• 证据来源
• 操作手册结构建议

如果项目材料不足、业务类型较新，或用户明确希望参考竞品，可联网搜索相近产品和行业资料；外部调研只用于理解行业表达，不能编造项目不存在的功能。调研摘要应写入业务理解草稿，并区分“项目证据”和“行业参考”。

生成 业务理解.md/json 后必须停止，等待用户确认或修改。业务理解确认前，不得生成申请表和操作手册。如果业务理解仍不充分，先请用户补充产品说明。用户确认后运行：

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

5. 引导用户确认字段

根据分析结果，向用户确认：

• 软件全称
• 版本号
• 著作权人
• 开发完成日期
• 首次发表日期或未发表
• 开发硬件环境
• 运行硬件环境
• 开发操作系统
• 运行平台/操作系统
• 开发工具（IDE 或编辑器名称）
• 运行支撑环境/支持软件（项目运行所需 Node.js、Python、Docker、数据库、浏览器、中间件或外部服务）
• 软件分类

项目可推断字段可以先给建议值；硬件/系统环境必须允许用户选择建议值或手动填写。字段口径必须区分清楚：

• 软件全称：必须由用户确认。最终正式资料文件名、代码 Word 页眉、操作手册标题和正文中的软件名称，都必须与 申请表信息.md 的“软件全称”字段一致。
• 版本号：必须由用户确认。优先读取项目配置中的版本号作为证据；如果项目版本号小于 V1.0（例如 V0.1.0、V0.9.0），必须明确询问用户“软著首次提交通常写 V1.0，本次填写 V1.0 还是项目当前版本号”。最终 申请表信息.md 的“版本号”字段就是正式资料版本号。
• 软件开发环境 / 开发工具：填写 IDE 或编辑器名称，例如 Visual Studio Code、WebStorm、IntelliJ IDEA、Cursor；不要把 React、Next.js、Vite、TypeScript 等技术栈写到此字段。
• 开发该软件的操作系统：填写实际开发电脑的操作系统版本，例如 Windows 10、Windows 11、macOS 14、macOS 15。
• 该软件的运行平台 / 操作系统：填写软件运行所在的操作系统版本，例如 Windows 10/11 或 macOS 13及以上版本。
• 软件运行支撑环境 / 支持软件：填写项目运行依赖的软件环境，例如 Node.js、Python、Docker、PostgreSQL、Redis、浏览器、中间件、外部模型或云服务。
• 开发的硬件环境：优先读取当前电脑 CPU、内存、硬盘、架构等配置作为建议值；读取不到时让用户填写。
• 运行的硬件环境：默认可沿用开发硬件环境建议值，也可以按实际部署或运行设备修改。

此阶段需要先停止等待用户输入；收到用户回复后，可整理为 answers JSON 传入申请表草稿生成。申请表字段的最终门禁在 草稿/申请表信息.md 生成后记录。

6. 确认代码文件选择

生成代码材料前，先运行候选文件分析：

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

输出：

• 草稿/代码文件候选清单.md：给用户看的候选说明。
• 草稿/代码文件选择.json：可编辑的选择文件。