tao-software-copyright

name	tao-software-copyright
description	从真实项目源码生成中文软件著作权登记材料。当用户提到"软著""软件著作权""软著申请资料""程序鉴别材料""文档鉴别材料/设计说明书""软著用户手册""采集表/申请表"时使用。 按阶段引导用户提供软件信息与代码路径，用内置参数化脚本生成：采集表(docx,按官方模板+形式校验)、程序鉴别材料(docx,源代码前30+后30页)、软件设计说明书(docx)、用户手册(docx,截图占位)+截图清单；设计说明书与用户手册二者择一作「文档鉴别材料」槽提交，不合并；定稿前必跑 validate(形式)+review(实质)两环。 代码只来自真实项目、绝不编造；只描述已实现功能；关键节点停下让用户确认。
allowed-tools	Read, Write, Edit, Bash, Glob, Grep, Agent, AskUserQuestion
metadata	{"short-description":"生成软著登记材料(代码/设计书/手册/采集表)"}

软件著作权登记材料生成

本 skill 把一套已成功下证的软著材料生产流程抽象为可复用工具。

软著只有两个上传槽位：①「程序鉴别材料」放源代码；②「文档鉴别材料」是一个槽位名，从 设计说明书 / 用户手册 / 操作手册 里三选一只放一份，绝不把多份拼接合并。「文档鉴别材料」不是某个文件的固定名字——本 skill 同时产出设计说明书与用户手册两份候选，交付前由用户指定哪一份进②号槽，另一份归档留痕不上传。

产出物：

1. 采集表.docx —— 由 gen_collection_form.py 按官方《新系统信息采集表》模板渲染（字段/选项/字符限制照搬官方），内置形式校验
2. 程序鉴别材料.docx —— 源代码，前30页+后30页（每页50行）；不足60页则全量 → 进①号槽
3. 软件设计说明书.docx —— 软件设计说明书（9章）→ ②号槽候选 A（亦作原创性留痕/尽调/维权材料）
4. 用户手册.docx + 截图清单.md —— 含截图占位，交用户/同事补图后重跑即嵌入 → ②号槽候选 B（默认推荐进②号槽：带截图+操作流程，最不易被打回）

② 号槽选哪份的判据：默认用户手册；仅当手册截图过多、有效文字版面页不足（版权中心按版面页计，整页大图“不经看”）时，改投偏文字的设计说明书，或给手册补文字——始终一份，不合并。

脚本是稳定资产，只负责渲染与分页；行业判断、模块设计、手册措辞由你（模型）阅读真实项目后决定。

铁律（违反即材料作废，务必遵守）

• 代码只来自真实项目源码，禁止编造任何源代码。
• 单一主体原则：软著任何材料中只允许出现「提交主体（著作权人）及其成员」。委托方/甲乙丙方/最终用户/合作方/客户单位及其对接人等任何其他主体或其人员一律不得出现——直接删除，不解释合作关系（越描越黑），服务对象改中立行业表述（如「面向城市治理场景」而非具体单位名）。即便实际是受托/分包开发，对外材料也只体现著作权人。生成后必须扫描并清除非著作权人主体/人员名称。
• 只交自研业务代码，避开开源框架/脚手架/通用模块（详见 references/code-selection.md）。基于开源框架/脚手架（如 Spring Boot / Django / Express / Create React App 等）时，框架代码版权非著作权人，纳入会被以"非原创"挑刺；并在采集表/说明书声明"基于 XX 开源框架(协议)二次开发，核心业务逻辑自主研发"。
• 只描述已实现的功能。 未实现、评审中、规划中的方案绝不写进设计说明书或手册（这是真实踩过的坑：写了"技术评审中"的未来方案会成为审查风险点）。
• 名称/版本号全程一致：采集表"软件全称/版本号" = 程序鉴别材料页眉 = 设计说明书封面/页眉 = 用户手册页眉 = 输出文件名。
• 「文档鉴别材料」是槽位不是文件名：设计说明书产出物命名 软件设计说明书.docx、手册命名 用户手册.docx，不得把任一份直接命名为 文档鉴别材料.docx（冒充槽位会让下游误判该交哪份）。交付前必须执行槽位指定（见下方工作流末步与 workflow.md 定稿门禁）。
• 关键节点必须停下确认，不得"用户没回就默认继续"。每个用户确认节点过后用 assets/scripts/gate.py confirm 机器化记录门禁；定稿 validate 环节 gate.py check --require ... 门禁不齐即拒绝交付。停顿门禁见 references/workflow.md。
• 硬件/系统环境、日期、著作权人不得硬编码，必须用户确认；模型不确定的字段过程中写 ★待确认，但定稿前必须 grep 清零——用 AskUserQuestion 逐项问实值替换，交付物中绝不残留 ★待确认。
• 采集表字段长度为登记系统强制限（超限即被打回）：开发工具/运行支撑环境 ≤50 字符、技术特点 ≤100 字符、主要功能 500–1300 字、开发目的/面向领域 ≤50 字。写完软件说明节逐项数长度再定稿，详见 references/application-form.md 七节。
• 输出目录默认在用户指定的软著工作目录（如 软著/<项目名>/），不要写到 /tmp。

三种入场模式（任一模式都必须归一到本 skill 新规则）

启动第一步先判定入场模式并与用户对齐，记 gate.py confirm --stage intake：

1. 全新：无任何已有材料，从工作流第 1 步顺序走。
2. 半道续作：已有部分草稿/中间产物（含本 skill 上次未跑完）。先盘点已有产物处于哪一步，缺失的前置门禁补确认，再从断点继续——不得跳过未确认的前置节点。
3. 老版本归一：手上是旧版本 skill、别的工具或人工产出的材料（如已有"文档鉴别材料.docx/操作手册/采集表 TXT"等）。一律不信任原样，必须过一遍归一审查：① 单一主体 grep 清除委托方/甲乙丙方/最终用户/对接人；② 采集表重灌 collection_form.json 跑 gen_collection_form.py --strict，补齐字符/字数硬限与官方字段；③ ★待确认 grep 清零；④ 厘清「文档鉴别材料」槽位、指定用哪份且不合并；⑤ 去 AI 味与"只写已实现功能"复核；⑥ 名称/版本全程一致。

铁律：无论哪种入场，最终都必须完整通过门禁 + validate(形式) + review(实质)，并符合本 skill 当前叙事与规则。老材料"看起来能用"不等于合规——经过本 skill 的产物就要按新规则负责到底。

启动时先问清楚（用 AskUserQuestion 收集）

参考 references/workflow.md 第 1 节，向用户收集并确认：

• 软件全称 / 简称 / 版本号（版本号<V1.0 时提示软著首提通常写 V1.0）
• 著作权人名称 + 统一社会信用代码；申请人联系方式
• 代码仓库路径（可多套：如 Java后端 / Vue前端 / Python SDK），各自语言与注释符
• 需求/功能清单来源（报价单、需求文档、PRD 或让模型从代码归纳）
• 参考资料（平台介绍、接入指南、docs/ 目录等，用于理解业务，不得据此编造功能）
• 截图策略（用 AskUserQuestion 三选一：① 模型用浏览器/MCP 自行截图 ② 用户/同事自截按清单归位 ③ 暂跳过留红色占位；任何方式产出的截图都要过合规复核，见下）
• 开发完成日期、首次发表日期、开发与运行软硬件环境
• 软著工作目录（材料输出位置）

信息不足时先停下让用户补，不要猜。

工作流（详见 references/workflow.md，按阶段执行，每阶段产出后停下确认）

1. 环境检查：python3 -c "import docx" 校验 python-docx；soffice 可选（用于核对页数）；python3 -c "import PIL" 可选（截图打码 redact_screenshot.py 用，缺则 pip install Pillow）。
2. 代码库勘察：对每套代码库用 Explore agent 或 grep/find 摸清目录结构、核心模块、技术栈版本、源码行数、数据库表、API 接口。摸清后向用户复述并确认理解无误。
3. 生成采集表：按 references/application-form.md 写 collection_form.json（示例 assets/scripts/example/collection_form.example.json，字段/选项措辞照搬官方模板），运行 assets/scripts/gen_collection_form.py --config ... --output 采集表.docx，看 stdout 形式校验报告，不确定项填 ★待确认，停下让用户核对。
4. 生成程序鉴别材料：写项目 project.json（见 assets/scripts/example/project.example.json），运行 assets/scripts/gen_code_doc.py --config project.json，报告总行数/页数。生成后必须敏感排查：扫描 docx 文本，配 scrub 删框架署名头(@Author/@Email/@Copyright 等含框架专有标识的整行，保留本团队@author)、掩码密钥/内网IP/内部域名，复扫确认归零（详见 references/code-selection.md、accuracy-rules.md）。
5. 生成文档鉴别材料：按 references/design-doc-outline.md 撰写 content_data.py（项目专属正文，基于真实代码/SQL/接口，类名表名不得编造），运行 assets/scripts/render_design_doc.py。推荐加第10章「开发历程与版本演进」：先用 gen_dev_history.py（只取用户确认的本团队 author，过滤开源框架/其他团队）提炼真实 git 时间线，再据此写入——作为创作时间与作者归属的举证。用 soffice 核对页数；不足时按 outline 补充真实章节，不靠注水。
6. 生成用户手册：按 references/manual-outline.md 写 manual.json（章节+截图位），运行 assets/scripts/gen_user_manual.py，自动产出 docx 与 截图清单.md。按用户所选截图方式（模型自截/用户自截/跳过）采集；任何截图入册前必做合规复核（见 workflow.md 6.2 / accuracy-rules.md 6bis）：剔除第三方主体名/LOGO/水印、个人隐私、内网IP/密钥/真实敏感数据，用 assets/scripts/redact_screenshot.py 按坐标打码（非破坏式），打码到不可辨认再嵌入。
7. validate —— 形式审查（SOP 必跑倒数第二环，保证“形式合规”）：① 跑 gen_collection_form.py --strict，ERROR 必须清零（字符/字数硬限、必填、★待确认）；② 三轮自检：四份材料文件完整、名称/版本/页数全程一致、单一主体 grep 归零、截图合规（无三方主体/隐私/敏感数据，需打码已打码）、grep -rn "★待确认" <软著目录> 零命中；③ 指定「文档鉴别材料」槽：用 AskUserQuestion 让用户在 软件设计说明书.docx/用户手册.docx 二选一（默认用户手册），选中那份复制为 文档鉴别材料（提交用）.docx，另一份标“归档不上传”，不合并不二传，记 gate.py confirm --stage doc-slot；④ 门禁齐全校验：gate.py check --workdir <软著目录> --require intake,business,collection-form,code-selection,screenshot-method,doc-slot，缺任一即停下补用户确认。任一项不过，不得进入 review。
8. review —— 实质审查（SOP 必跑最后一环，保证“实质真实”）：逐项核内容真实性——代码可回溯真实源码；设计书/手册的类名表名接口对得上真实项目；只写已实现功能（无规划/评审中内容）；服务对象为中立行业表述；技术特点与功能描述非注水套话。形式过了≠能交，给出 review 结论、用户同意后记 gate.py confirm --stage review-signoff 方可定稿。无论全新、半道续作还是老版本归一，门禁→validate→review 都是定稿前不可跳过、不可调换顺序的收尾。
9. （可选）原创性留痕：涉及维权/投融资尽调价值时，按 references/evidence-trail.md 用 inject_copyright_header.py（默认 dry-run，确认并切独立分支后 --apply 把版权头写进真实自研源码）+ gen_evidence_manifest.py 生成《原创性举证清单.md》。改动真实仓库前必须用户明确同意。

调用脚本（参数化，稳定资产）

SK=<本skill绝对路径>/assets/scripts
python3 "$SK/gate.py" confirm --workdir <软著目录> --stage <阶段> --note "用户确认内容"
python3 "$SK/gate.py" check  --workdir <软著目录> --require intake,business,collection-form,code-selection,screenshot-method,doc-slot
python3 "$SK/gen_collection_form.py" --config <软著目录>/collection_form.json \
        --output <软著目录>/采集表.docx [--strict]   # --strict 供 validate 环节
python3 "$SK/gen_code_doc.py"     --config <软著目录>/project.json
python3 "$SK/render_design_doc.py" --content <软著目录>/content_data.py \
        --header "<软件全称> <版本>" --title "软件设计说明书" \
        --unit "<著作权人>" --output <软著目录>/软件设计说明书.docx
python3 "$SK/gen_user_manual.py"  --spec <软著目录>/manual.json \
        --header "<软件全称> <版本>  用户手册" \
        --screenshot-dir "<软著目录>/物料/screenshots" \
        --output "<软著目录>/用户手册.docx" \
        --manifest "<软著目录>/截图清单.md"
# 截图打码（隐私/三方主体脱敏，非破坏式，默认 dry-run）
python3 "$SK/redact_screenshot.py" --manifest <软著目录>/打码清单.json        # 预演
python3 "$SK/redact_screenshot.py" --manifest <软著目录>/打码清单.json --apply # 执行

content_data.py 与 manual.json 由你按 references 为每个项目现写；project.json 按示例填路径。脚本不改。

何时停下问用户

• 多个代码库/项目候选需要指定
• 软件名称、版本、著作权人、日期、软硬件环境需确认
• 业务理解（行业/目标用户/核心功能）复述后需用户确认
• 采集表生成后需用户核对 ★待确认 项与形式校验报告中的 ERROR
• 设计说明书页数不足、需决定补充哪些真实内容
• 截图策略选择（模型自截需用户给环境地址与凭据）
• 截图合规复核发现三方主体/隐私/敏感数据时，确认打码方案或改用脱敏环境重截
• validate 通过后、review 实质审查结论需用户确认，方可定稿交付

详细阶段门禁、撰写规范与反"AI味"要求见 references/ 下各文件，开工前务必先读 references/workflow.md、references/accuracy-rules.md（含已验证下证基线，勿过度加码）与 references/code-selection.md；涉及维权/尽调时读 references/evidence-trail.md。