software-copyright

name	software-copyright
title	软著申请资料生成
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.
author	kevinnft
author_url	https://github.com/kevinnft/ai-agent-skills/tree/main/skills/software-copyright
license	MIT
version	0.1.0
execution_mode	open
jurisdiction	cn
practice	ip
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： 生成后，用户必须补全并确认硬件、系统环境、著作权人、日期等字段。