/software-copyright

name: software-copyright
description: >
  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.
metadata:
  short-description: 生成软著申请资料 Word/TXT
origin: unknown
source_license: see upstream
language: zh

软著申请资料生成

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

• 固定输出目录：当前工作目录下的 `软件著作权申请资料/`。不要默认写到 `/tmp`、`/private/tmp` 或其他临时目录。
• 只有测试 skill 自身时才允许显式指定临时目录；面向用户生成材料时必须写入当前目录。
• 先生成 Markdown 草稿，用户确认后再生成正式 Word/TXT。
• 正式 Word/TXT 只能写入 `软件著作权申请资料/正式资料/`，不要散落在输出目录根部。
• 正式 Word/TXT 的文字一律使用默认黑色字体，不生成蓝色超链接、主题色标题或其他彩色文字；Markdown 链接写入 Word 时必须转成普通文本。
• 正式资料中的软件名称必须与 `草稿/申请表信息.md` 的“软件全称”字段一致；正式生成时以已确认的申请表软件全称为准。
• 正式代码 Word 页眉中的版本号必须与 `草稿/申请表信息.md` 的“版本号”字段一致；正式生成时以已确认的申请表版本号为准。
• 代码材料必须来自真实项目源码，禁止 AI 编造代码。
• 写申请表和操作手册前，必须先形成模型研判后的 `草稿/业务理解.md/json`，理解软件业务、行业、目标用户、核心价值和操作流程。
• 脚本只能收集项目证据、校验字段和生成文件；行业判断、功能抽取、代码抽取选择、操作手册结构必须由模型阅读项目后决定，不得依赖脚本关键字表或固定范本。
• 优先抽取前端代码：入口、路由、页面、核心组件、接口封装、状态管理、工具函数。
• 生成代码材料前，必须先生成代码文件候选清单；模型理解项目后填写抽取文件、行段和选择理由，再让用户确认或修改。
• 代码优先抽取模型和用户确认的、最能体现软件真实功能和运行逻辑的源码；不足 60 页时，从其他相关源码文件补充到 60 页；候选源码仍不足 60 页时，才生成全部代码文档。
• 操作手册面向审核员，用通用语言说明软件用途和操作流程。
• 操作手册草稿必须按章节写成通顺段落，不能只给功能列表；每个核心模块都要用普通人能看懂的语言说明模块用途、操作过程和结果反馈。避免代码、框架、接口、状态管理、异步任务等技术化表达；撰写过程中由 agent 自行循环检查、扩写和修正，完整草稿完成后只向用户发起一次整体确认。
• 操作手册必须去除明显“AI 味”：避免空泛赞美、营销口号、万能句式、每章同一结构、过度对称的排比、没有项目细节的正确废话、频繁使用“旨在、赋能、一站式、智能化、高效便捷、显著提升、强大能力、丰富功能”等套话。每段都应能回答“这个项目里这个功能具体做什么、用户看见什么、操作后有什么结果”。
• 操作手册生成必须同步输出 `草稿/操作手册自检记录.md` 和 `草稿/操作手册自检记录.json`，记录初稿、按项目流程扩写、去制式表达等自检轮次；如果前 3 轮仍发现问题，必须继续补写修正，直到问题清零或记录无法自动修复的原因后再停止。
• 截图方式必须先让用户选择：Chrome DevTools MCP、Codex Computer Use、用户自行截图。用户选完后，再检查当前 MCP / Computer Use 能力是否可用；如果用户说现在不截图、先跳过截图或截图失败，操作手册仍必须保留清晰可见的截图预留位置，正式 Word 中也要能看到。
• 申请表信息中的硬件/系统环境必须让用户确认或填写，不能硬编码。
• Word 生成能力必须使用本 skill 内置的 `vendor/docx-toolkit`；不得引用外部 DOCX 目录。

强制人工门禁

凡是涉及用户选择、确认或补充信息的阶段，必须先停止当前执行，不得继续调用下一步脚本。即使处于自动审核、自动继续或无人值守模式，也必须把 `STOP_FOR_USER` 和 `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`
• `business_feature_details`
• `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 等技术栈写到此字段。
• 开发