skills/code2patent/SKILL.md
从已开发代码项目中提取技术实现证据,围绕候选专利方案生成算法/软件类说明书式技术交底书,并以“权利要求布局卡 → 发明专利初稿”两步法继续生成接近可申报版的中国发明专利起草材料。触发场景包括:读取代码仓库后撰写技术交底书、将人工总结的专利方案映射到具体实现、从代码中挖掘可专利技术方案、为专利代理师准备权利要求布局和发明专利初稿。
npx skillsauth add cat-xierluo/legal-skills code2patentInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
本技能用于把已经开发完成的代码项目整理成专利代理师可继续起草和判断的材料。核心目标不是把代码翻译成专利语言,而是把真实实现、技术问题、技术方案、技术效果和证据位置整理成可追溯的发明专利底稿。
默认法域为中国发明专利,主要适用于软件、算法、Agent 系统、调度优化、状态表示、鉴权、记忆、上下文编排和文件系统等以代码实现为主的方案。
推荐主链路:
用户材料 + 代码仓库
↓
输入成熟度判断 + archive 归档目录
↓
项目边界与依赖画像
↓
方案-代码证据映射
↓
算法/软件类说明书式技术交底书
↓
权利要求布局卡 + 权利要求-证据矩阵
↓
发明专利初稿 + 初稿自检表
开始读取代码前,先确认:
archive/YYYY-MM-DD-主题/。专利名称不是技术方案。 如果用户只给标题或一句话方向,不要直接写交底书或初稿。
| 等级 | 输入状态 | 默认动作 | |------|----------|----------| | T0 名称清单 | 只有专利名称、标题或一句话方向 | 输出《专利名称反向澄清卡》,等待用户确认 | | T1 方向清单 | 有名称和业务方向,但缺少技术问题、实现路径或效果 | 先补齐候选解释、代码证据方向和待确认问题 | | T2 技术方案清单 | 已有技术问题、核心实现、目标效果和初步模块范围 | 进入定向检索,生成代码证据映射和交底书 | | T3 证据型方案清单 | 已有技术方案、代码路径、关键流程和证据等级 | 复核证据后继续生成交底书、布局卡或初稿 | | 无清单 | 用户希望从代码中挖掘专利点 | 先输出候选可专利方案清单,人工筛选后再起草 |
未经人工确认的 T0/T1 或自动挖掘结果,只能作为候选方向,不得写成客户已确认的技术方案。
执行时先读用户提供材料,再读代码。建议顺序:
如果用户提供模板或样本,先抽取章节结构、步骤编号、附图习惯和技术效果写法,再生成交付物。若未提供模板,按 references/algorithm-software-disclosure-format.md 和内置模板执行。
只在需要时读取对应文件,避免把所有 reference 一次性装入上下文。
| 需要处理的问题 | 读取文件 |
|----------------|----------|
| 算法/软件类交底书结构、S1...Sn、代码证据后置规则 | references/algorithm-software-disclosure-format.md |
| 项目技术方案画像、依赖边界、自研与第三方能力区分 | references/project-analysis-spec.md |
| S/F/E 抽取、A/B/C 分级、从代码到专利表达的转译 | references/code-extraction-spec.md |
| 快速进入布局卡、初稿和自检写作 | references/patent-drafting-quick-reference.md |
| 需要完整起草依据、权利要求层级和摘要规则 | references/patent-drafting-spec.md |
本文件只保留入口、分流、路由和强规则;细节规则以后优先维护在 references/。
| 目标产物 | 模板 |
|----------|------|
| 专利名称反向澄清卡 | templates/patent-title-clarification-card-template.md |
| 算法/软件类发明专利技术交底书 | templates/invention-patent-disclosure-template.md |
| 权利要求布局卡 | templates/invention-patent-claim-layout-template.md |
| 权利要求-证据矩阵 | templates/invention-patent-claim-evidence-matrix-template.md |
| 发明专利初稿 | templates/invention-patent-draft-template.md |
| 发明专利初稿自检表 | templates/invention-patent-draft-self-check-template.md |
templates/ 是可直接填充的交付骨架;references/ 是执行规则和判断标准。不要把二者合并。
05-技术交底书、05A-权利要求布局卡、05B-权利要求-证据矩阵、06-发明专利初稿 中的 S1...Sn 步骤编号应保持一致。| 层级 | 适用场景 | 主要产物 | |------|----------|----------| | L0 名称反向澄清 | 用户仅提供专利名称、标题或一句话方向 | 专利名称反向澄清卡 + 人工确认记录 | | L1 代码证据映射 | 已有候选方案,需判断是否落在代码实现上 | 方案-代码证据映射表 | | L2 技术交底书 | 当前最推荐主产物 | 算法/软件类说明书式技术交底书 + 必要证据附录 | | L2.5 权利要求布局 | 需要推进到申请文件层但先稳住 claim tree | 权利要求布局卡 + 权利要求-证据矩阵 | | L3 发明专利初稿 | 需要代理撰写前的完整初稿 | 说明书初稿 + 权利要求草稿 + 摘要 + 自检表 | | L4 可专利方案挖掘 | 用户尚未总结候选方案 | 候选方案清单 + 优先级建议 + 人工筛选记录 |
按目标层级裁剪执行,不必每次输出全部文件。
archive/YYYY-MM-DD-主题/。archive/YYYY-MM-DD-主题/
├── 00-输入材料摘要.md
├── 01-专利名称反向澄清卡-待确认.md
├── 01A-人工确认记录.md
├── 02-项目边界与依赖画像.md
├── 03-项目技术方案画像.md
├── 04-方案代码证据映射-<方案名>.md
├── 05-技术交底书-<方案名>.md
├── 05A-权利要求布局卡-<方案名>.md
├── 05B-权利要求-证据矩阵-<方案名>.md
├── 06-发明专利初稿-<方案名>.md
├── 06A-发明专利初稿自检表-<方案名>.md
└── 07-研发补充问题清单.md
若当前是候选方案挖掘模式,先输出 03-候选可专利方案清单-待人工筛选.md 和 04-优先申请建议.md,待用户确认后再进入定向检索。
软件、算法和 Agent 系统方案的技术交底书默认使用以下顺序:
如果正文中连续出现多个代码路径、函数名或字段名,应回退重写,将其移入 04-方案代码证据映射-<方案名>.md 或证据附录。
data-ai
当用户要求你并行推进多个任务、一次性开多个 worker/agent 同时工作、用 tmux 启动多个独立 session、防止 PM 直接实现逃逸、或者你作为 PM 需要拆解并派发任务给多个独立 worker 时使用。触发词包括"并行推进""开多个""同时推进""派 worker""多 agent 并行""开 worker""tmux 启动""独立 session""防逃逸""分派任务""一起做"。不要用于单个短任务、跨平台任务状态管理、或 Git 分支/提交/PR/merge 安全规则。
tools
本技能应在 GitHub 项目发布新版本时使用,覆盖版本号管理、CHANGELOG 同步、Release Notes 撰写、tag 创建、CI 构建监控、发布验证和历史清理全流程。适用于桌面应用、CLI 工具、Web 应用、库/SDK 等任何基于 GitHub 的软件项目。当用户提到"发布"、"release"、"打 tag"、"新版本"、"更新版本号"、"写 release notes"、"发布失败了"、"CI 挂了"时触发。不要用于非 GitHub 项目(如纯 GitLab / Gitea 项目)或无需 CI 的手动发布场景。
content-media
本技能应在用户需要 OCR、扫描识别、图片文字识别、文档识别,或将 PDF、图片、Office 文档、URL 转换为 Markdown 时使用。检测到法律材料时可进行保守的法律术语与文书结构优化。不要用于法律事实判断、补写缺失内容、语义改写、印章深度识别或图表实体分析。
tools
将 monorepo 中的子目录通过 git subtree 推送到独立 GitHub 仓库。支持注册清单、变更自动检测、增量推送。本技能应在用户提交涉及已注册子项目的变更后,或手动请求推送到独立仓库时使用。不要用于初次创建 monorepo 或管理 git submodule。