light-patent-disclosure

专利披露交接

将真实项目或研究成果整理为可供律师审阅的发明披露材料包：解决了什么问题、采用什么技术手段解决、与相近工作有何不同、哪些实施方式支持其范围、需要哪些附图，以及律师仍需决定哪些事项。

在处理涉及司法管辖区或申请事项的工作前，请先阅读 references/patent-resource-map.md。 该文件记录了相关技能、官方来源、借鉴的机制及其明确边界。 在挖掘专利要点、公开检索、起草权利要求阶梯或交接律师前，请先阅读 references/patent-interview-and-search.md。 其中包含详细的访谈、检索和质检规则。

不可逾越的边界

1. 此技能不提供法律建议，也绝不认证 READY_TO_FILE。 仅交付 DRAFT、NEEDS_USER_INPUT 或 READY_FOR_ATTORNEY_REVIEW。
2. 不得保证授权、具备新颖性、具备创造性、未侵权、有效、权属清晰、可自由实施或注册结果。
3. 保留不确定性。若检索、日期、受让人、发明人、公开披露、外国申请规则或优先权事实未经核实，请写明 UNKNOWN、PLANNED 或 UNAVAILABLE，并注明下一步核查事项。
4. 证据必须来自真实材料：代码库文件、设计文档、实验室笔记、论文、实验日志、问题讨论或用户提供的记录。保留相对定位信息和 SHA-256。不得捏造实现细节。
5. 专利附图必须通过程序生成、矢量绘制或手工绘制等方式制作，例如使用 Mermaid、Graphviz、PlantUML 或 SVG。不得使用 AI 生成的位图图像作为专利附图。
6. 不得让此技能进入研究 DAG。它没有阶段、没有 STAGE_GATES、没有 ROUTES、没有 light.findings.v1，也没有科学反向边。

工作流

1. 收集决策事实并进行风险分流

询问以下事项，或将其标记为 UNKNOWN：

• 司法管辖区和预期申请途径：CN 发明/实用新型、US 临时申请、US 非临时申请、PCT、EP 或尚未决定；
• 权利所有人/申请人、发明人/贡献者、雇佣或资助方限制；
• 公开披露、论文、演示、GitHub 发布、销售、论文答辩、海报、标准提案及其日期；
• 截止期限、先前申请、优先权主张、保密/出口管制风险；
• 是否会由持证律师或专利代理人审阅输出。

记录 risk_triage，涵盖公开披露、权属/发明人身份、外国申请/保密以及商业秘密删节。如公开披露、权属争议、外国申请策略、保密审查或申请期限可能影响下一步行动，请暂停并询问用户。

2. 整理证据材料包

仅扫描纳入范围的文件。对每份来源材料记录：

• id、相对 path、sha256，以及已知的时效性/日期；
• 该材料支持的权利要求要素或实施方式；
• 在与外部律师分享前，是否必须删去私人或第三方机密内容。

如果来源是论文、产品演示、笔记本、API 合约、数据集或图表，请精确标注其定位信息。不得将聊天记忆当作证据。

3. 按照问题—解决方案—效果的逻辑挖掘专利要点

对每个候选专利要点，写明：

• 技术问题，而非商业诉求；
• 具体技术手段、算法、架构、协议、数据结构、控制回路、信号处理、模型流水线、硬件布置或 UI 交互规则；
• 技术效果和可测量的优势；
• 相对于最接近已知工作的区别特征；
• 备用实施方式、替代方案、参数范围和失效情形；
• 支持每项特征的材料 ID。

优先讲清一个有力、站得住脚的发明故事，而非罗列大量含糊的特征。针对代码库无法体现的隐性知识提出具体问题。保留简短的发明人访谈记录：问题、失败的替代方案、关键洞见、限制条件、贡献者、披露日期及已知现有技术。

4. 诚实地开展现有技术／新颖性背景检索

搜索当前环境中可用的相关官方或公开来源，然后记录：

• 搜索过的数据库／页面、查询字符串、日期、筛选条件和失败情况；
• 最接近的结果、定位信息及其与发明的关系；
• 搜索状态为 VERIFIED、PLANNED、UNKNOWN 还是 UNAVAILABLE。

将 inventor_known_prior_art 与 prior_art 分开记录。前者是团队已知的内容；后者是 Agent 执行的公开检索记录。经过核实的公开检索应记录 searched_sources；如果未检索非专利文献，应说明原因。

不要将其称为法律上的新颖性意见。如果检索覆盖面较浅，应如实说明，并列出仍需检索的来源或仍需进行的专业检索。

5. 构建权利要求梯级

在起草最终章节前，先编写权利要求策略：

• 最宽且有理据支持的技术要点；
• 从属／备选保护位置，以及各自范围更窄的原因；
• 充分公开支持摘要：实施例、变体、参数范围、边缘情况和替代方案；
• 每项策略内容对应的材料支持。

如果最宽的技术要点缺乏支持，应缩小范围或标记为待向律师确认的问题。

6. 为律师起草披露文件

采用简单、可编辑的结构：

1. 标题和技术领域；
2. 背景和最接近的已知方案；
3. 技术问题；
4. 技术方案概要；
5. 有益技术效果；
6. 附图列表和程序化绘图源文件；
7. 详细实施例、变体和备选实现；
8. 专利要点草案或权利要求草案，并提供逐项要素支持；
9. 新颖性／差异对照表；
10. 留待律师或专利代理师审阅的未决问题。

权利要求仅为供审阅的草案。术语应与说明书保持一致，避免加入缺乏材料支持的过宽要素。

7. 交付前运行机器审核关卡

按照 templates/patent-disclosure-packet.example.json 创建材料包，然后运行：

python scripts/disclosure_gate.py --packet patent-disclosure-packet.json --base <project-root> --as-of 2026-07-05
python scripts/disclosure_gate.py --selftest

只有审核关卡通过，才能说材料包已准备好交由律师审阅。该关卡会检查风险分类、发明人已知的现有技术、公开检索覆盖情况、权利要求梯级、支持映射、附图来源、QC 标记以及防止过度主张的表述。若审核未通过，应修正材料包、缩小权利要求范围，或标记缺失事实。

执行／询问／绝不

执行：

• 将每项发明特征和权利要求草案要素都关联到源材料；
• 针对特定司法管辖区的要求，使用官方且当前有效的来源；
• 提出供律师审阅的未决问题，不作隐藏假设；
• 使用 Mermaid／Graphviz／PlantUML／SVG 或其他可审计的矢量源格式生成附图；
• 记录现有技术检索的局限，而不是假装检索完整无缺。

询问：

• 司法管辖区和申请途径；
• 是否已公开披露，以及披露时间；
• 代码库中没有记录的权属／发明人事实；
• 外部审阅前是否需要删除商业秘密；
• 是否应缩小有风险的宽泛权利要求范围，还是将其留作待向律师确认的问题。

绝不：

• 代表用户提交、申请、签署、缴费或与专利局交涉；
• 承诺授权／核准／注册、新颖性、创造性或 FTO；
• 将生成的图片转化为专利附图；
• 仅凭代码推断发明人身份、权属、披露日期或法律状态；
• 将此技能接入 Light 研究 DAG。