从真实项目生成中国软件著作权申请资料（Word/TXT）。支持项目分析、代码材料抽取、申请表信息生成和操作手册撰写，输出符合软著申报要求的正式材料。
/plugin install software-copyright-materials@datou-market/plugin marketplace add https://github.com/Garretqaq/plugins-market这个 skill 生成可审阅、可追溯的软著申请资料。核心原则：
软件著作权申请资料/。不要默认写到 /tmp、/private/tmp 或其他临时目录。软件著作权申请资料/正式资料/，不要散落在输出目录根部。草稿/申请表信息.md 的“软件全称”字段一致；正式生成时以已确认的申请表软件全称为准。草稿/申请表信息.md 的“版本号”字段一致；正式生成时以已确认的申请表版本号为准。草稿/业务理解.md/json，理解软件业务、行业、目标用户、核心价值和操作流程。一、相关文档，不得使用 (1)、相关文档。相关文档必须用表格指向总体设计、详细设计、测试案例等配套文档。正文尽量使用连续段落，不使用项目符号列表或 1. 2. 3. 编号列表。草稿/操作手册自检记录.md 和 草稿/操作手册自检记录.json，记录初稿、按项目流程扩写、去制式表达等自检轮次；如果前 3 轮仍发现问题，必须继续补写修正，直到问题清零或记录无法自动修复的原因后再停止。vendor/docx-toolkit；不得引用外部 DOCX 目录。凡是涉及用户选择、确认或补充信息的阶段，必须先停止当前执行，不得继续调用下一步脚本。即使处于自动审核、自动继续或无人值守模式，也必须把 STOP_FOR_USER 和 NEXT_ACTION 原样告知用户，并等待用户输入后再继续。
禁止使用“用户未选择则默认继续”的逻辑。用户回复确认后，先用确认脚本记录对应门禁，再进入下一阶段：
python3 ${CLAUDE_SKILL_DIR}/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 生成。一开始先在当前工作目录创建输出目录并检查运行能力：
python3 ${CLAUDE_SKILL_DIR}/scripts/check_environment.py \
--out-dir 软件著作权申请资料
输出：
软件著作权申请资料/环境检查.md软件著作权申请资料/环境检查.json环境检查必须告诉用户：
vendor/docx-toolkit 的完整 OpenXML 环境是否可用。.NET SDK 缺失，询问用户是否安装完整环境。用户选择：
${CLAUDE_SKILL_DIR}/vendor/docx-toolkit/scripts/setup.sh 的要求安装依赖，再继续。完整环境生成和校验更规范。用户回复后记录门禁：
python3 ${CLAUDE_SKILL_DIR}/scripts/confirm_stage.py \
--workdir 软件著作权申请资料 \
--stage environment \
--note "<用户选择>"
不要等到最后验证阶段才发现完整 DOCX 环境不可用；这个信息必须在流程开始时给出。
用户通常会把项目放在当前文件夹下。先扫描当前目录，避开本 skill、自身输出目录、node_modules、构建产物和隐藏目录，找到最可能的项目根目录。
如果有多个候选项目，必须停止并询问用户选择；如果只有一个明显候选项目，可以直接使用。
运行：
python3 ${CLAUDE_SKILL_DIR}/scripts/analyze_project.py \
--project <项目目录> \
--out 软件著作权申请资料/analysis/project.json
分析内容包括：
package.json、README、脚本命令、依赖在写申请表和操作手册前，先让脚本收集项目证据：
python3 ${CLAUDE_SKILL_DIR}/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_sectionsmanual_modulessystem_requirementsfaqglossary其中 manual_modules 是操作手册的核心输入，必须按真实页面、导航入口或业务流程填写。脚本不得按 auth/query/form 等分类模板自动补入口、步骤或反馈；缺少 manual_modules 或关键字段时必须停止让模型回到项目证据中补写。每个模块必须包含：
title：页面或流程名称。evidence：对应页面、路由、组件、需求文档或 README 证据。purpose：该页面在软件中的用途。usage 或 usage_scenario：用户在什么业务场景下会使用该页面，正在处理什么具体事务。缺少时不得生成操作手册。entry：用户从哪里进入该页面。visible_elements：用户实际能看到的输入框、按钮、列表、标签、状态或结果区域。operation_steps：按真实页面顺序写用户动作，不能写代码实现。validation_rules：必填项、长度限制、权限、额度、状态、异常提示等规则；没有则留空数组。feedback：操作完成后用户能看到的结果、提示或状态变化。screenshot：截图预留说明。manual_sections 只允许补充当前软件本身的用途、业务场景、页面组织或用户流程，不要写“本操作手册用于……”“面向软著审核……”“不描述代码实现……”这类解释文档写作方式的元话语。最终操作手册应像真实软件说明书，而不是生成过程说明。
然后运行：
python3 ${CLAUDE_SKILL_DIR}/scripts/generate_business_context.py \
--project <项目目录> \
--analysis 软件著作权申请资料/analysis/project.json \
--software-name "<软件全称>" \
--out-dir 软件著作权申请资料/草稿 \
--model-context <模型生成的业务理解JSON>
输出：
草稿/业务理解.md草稿/业务理解.json最终业务理解必须覆盖：
如果项目材料不足、业务类型较新，或用户明确希望参考竞品，可联网搜索相近产品和行业资料；外部调研只用于理解行业表达，不能编造项目不存在的功能。调研摘要应写入业务理解草稿，并区分“项目证据”和“行业参考”。
生成 业务理解.md/json 后必须停止，等待用户确认或修改。业务理解确认前，不得生成申请表和操作手册。如果业务理解仍不充分，先请用户补充产品说明。用户确认后运行：
python3 ${CLAUDE_SKILL_DIR}/scripts/confirm_stage.py \
--workdir 软件著作权申请资料 \
--stage business \
--note "<用户确认内容>"
根据分析结果，向用户确认以下字段（按官网实际表单顺序）：
项目可推断字段可以先给建议值；硬件/系统环境必须允许用户选择建议值或手动填写。字段口径必须区分清楚：
申请表信息.md 的"软件全称"字段一致。申请表信息.md 的"版本号"字段就是正式资料版本号。开发环境: <操作系统>/开发工具: <IDE名称>，例如 开发环境: Windows 11/开发工具: Visual Studio Code；不要把 React、Next.js、Vite、TypeScript 等技术栈写到此字段。此阶段需要先停止等待用户输入；收到用户回复后，可整理为 answers JSON 传入申请表草稿生成。申请表字段的最终门禁在 草稿/申请表信息.md 生成后记录。
生成代码材料前，先运行候选文件分析：
python3 ${CLAUDE_SKILL_DIR}/scripts/propose_code_selection.py \
--project <项目目录> \
--analysis 软件著作权申请资料/analysis/project.json \
--out-dir 软件著作权申请资料/草稿
输出：
草稿/代码文件候选清单.md：给用户看的候选说明。草稿/代码文件选择.json：可编辑的选择文件。脚本生成的候选清单只列证据，不默认选择文件。模型必须先阅读业务理解、候选文件、入口文件、页面文件和必要源码，判断哪些源码最能体现软件真实功能和运行逻辑，然后修改 代码文件选择.json：
selected: true 表示抽取该文件。selected: false 表示不抽取该文件。model_reason 必须说明为什么选择该文件。模型选择通常优先考虑前端入口、页面、核心组件、业务交互、数据请求、状态处理等能给审核员看懂软件功能的代码；如果相关前端代码不足 60 页，再补充后端服务、业务处理等相关源码。补充文件同样必须写入 代码文件选择.json 并由用户确认。不要默认抽取全量代码库。代码材料按完整文件抽取并去除纯空行，不支持只抽取某个文件的中间行段。用户确认并记录 code-selection 门禁后，代码抽取只读取 代码文件选择.json 中选中的完整文件。用户确认后运行：
python3 ${CLAUDE_SKILL_DIR}/scripts/confirm_stage.py \
--workdir 软件著作权申请资料 \
--stage code-selection \
--note "<用户确认内容>"
运行代码材料抽取：
python3 ${CLAUDE_SKILL_DIR}/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，用于追溯代码来源。生成申请表信息草稿：
python3 ${CLAUDE_SKILL_DIR}/scripts/generate_application_info.py \
--analysis 软件著作权申请资料/analysis/project.json \
--code-manifest 软件著作权申请资料/草稿/代码提取清单.json \
--business-context 软件著作权申请资料/草稿/业务理解.json \
--software-name "<软件全称>" \
--version "<版本号>" \
--out-dir 软件著作权申请资料/草稿
生成后必须停止，让用户检查并补全 草稿/申请表信息.md。字段补全并确认后运行：
python3 ${CLAUDE_SKILL_DIR}/scripts/confirm_stage.py \
--workdir 软件著作权申请资料 \
--stage application-fields \
--note "<用户确认内容>"
生成操作手册草稿：
python3 ${CLAUDE_SKILL_DIR}/scripts/generate_manual_draft.py \
--analysis 软件著作权申请资料/analysis/project.json \
--business-context 软件著作权申请资料/草稿/业务理解.json \
--software-name "<软件全称>" \
--version "<版本号>" \
--out-dir 软件著作权申请资料/草稿
操作手册草稿不得照抄用户提供的范本文案或旧项目内容，但应吸收其结构特点：先写相关文档、说明、功能特点和系统要求，再按真实页面或核心流程逐章说明操作，最后写常见问题解答和术语表。一级章节标题使用中文大写序号；相关文档章节必须是表格；功能特点和页面操作章节必须以段落展开，不用项目符号和编号列表堆信息。必须基于模型写入 草稿/业务理解.json 的 manual_modules 组织章节；manual_sections 只用于补充说明性段落，不应用来反复插入同一批功能模块。各功能章节必须写清页面用途、进入位置、用户看到的控件和数据、实际操作、输入限制或异常提示、操作结果和截图预留。语言要面向普通用户，说明“这个页面是干嘛的、用户怎么进入、用户点什么/填什么、操作后看到什么”，不要写代码实现、框架名称、接口封装、状态管理、异步队列等技术细节。撰写时由 agent 自行检查章节是否完整、内容是否过薄、语言是否过于技术化，并在草稿内部完成必要补写；完整草稿完成后只让用户做一次整体确认，确认前不得进入正式 Word/TXT 生成。
生成脚本必须同时写出 草稿/操作手册自检记录.md 和 草稿/操作手册自检记录.json。自检记录至少包含：
操作手册的模块写作必须从 草稿/业务理解.json 的行业、目标用户、核心价值、业务功能、典型操作流程和 manual_modules 出发。不同模块要写出各自的业务作用、入口、控件、规则和反馈，不能统一套用“进入页面、填写内容、提交按钮、查看结果”的固定句式，也不能使用“进入方式：/页面内容：/操作步骤：/操作规则：/操作结果与反馈：”这类字段标题；相近模块也要结合项目真实业务区分各自的操作目的和结果。自检时必须检查是否把同一批模块在多个章节中重复展开；如发现重复，改为每个真实页面或流程独立成章。不得把测试项目的功能名称、业务流程或示例文案写成通用规则。
操作手册草稿完成后，先停止并让用户选择截图方式，必须给出三种选项：
软件著作权申请资料/用户截图/，agent 只负责整理和引用。如果用户明确说“现在不截图”“先跳过截图”“这次不截图”，也必须记录截图方式门禁，方法填 skip。跳过截图不阻塞正式资料生成，但操作手册中每个核心功能模块必须保留可见的截图预留文字，例如：【截图预留：请在此处插入“项目管理”页面或操作结果截图。】。不要使用 HTML 注释作为截图占位，因为正式 Word 中看不到。
用户选择后，先记录门禁：
python3 ${CLAUDE_SKILL_DIR}/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。python3 ${CLAUDE_SKILL_DIR}/scripts/capture_screenshots.py \
--manual-dir 软件著作权申请资料/用户截图 \
--out-dir 软件著作权申请资料/截图
截图成功后，把截图引用补入 草稿/操作手册.md；截图失败或用户选择暂不提供截图时，继续生成带截图预留位的文字版，并在报告中说明“操作手册截图未生成或未插入，已保留截图预留位置”。
生成 Word 前，必须让用户确认 软件著作权申请资料/草稿/ 下的 Markdown。
重点检查：
申请表信息.md 的“软件全称”一致申请表信息.md 的“版本号”一致申请表信息.md 的“软件全称”和“版本号”业务理解.md 是否准确反映软件真实业务、行业和目标用户申请表信息.md 中“待用户确认”的字段是否已确认用户确认后，必须记录 markdown 门禁；未记录时不得生成正式 Word/TXT。
python3 ${CLAUDE_SKILL_DIR}/scripts/confirm_stage.py \
--workdir 软件著作权申请资料 \
--stage markdown \
--note "<用户确认内容>"
用户确认后运行：
python3 ${CLAUDE_SKILL_DIR}/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 和项目文档。可用命令：
python3 -m py_compile ${CLAUDE_SKILL_DIR}/scripts/*.py
bash ${CLAUDE_SKILL_DIR}/vendor/docx-toolkit/scripts/docx_preview.sh <生成的docx>
完整 DOCX 环境检查和安装必须直接恢复/构建 ${CLAUDE_SKILL_DIR}/vendor/docx-toolkit/scripts/dotnet/DocxToolkit.Cli/DocxToolkit.Cli.csproj，不要对 vendor/docx-toolkit/scripts/dotnet 目录或 .slnx 文件执行隐式 restore/build。
如果 环境检查.md 或 ${CLAUDE_SKILL_DIR}/vendor/docx-toolkit/scripts/env_check.sh 显示 .NET SDK 缺失，说明完整 DOCX OpenXML 校验环境未就绪。用户明确选择不安装并记录 environment 门禁后，继续生成 Markdown、TXT 和基础 DOCX，并在报告中说明当前使用兜底路径。
以下场景必须询问并停止，等待用户输入后再继续：
代码文件选择.json。