Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Convert finished research papers, figures, and author notes into Chinese invention patent application drafts. Use when Codex needs to rewrite a paper as a China invention patent, draft claims, abstract, specification sections, and figure descriptions, assess whether the source materials are sufficient for patent drafting, or produce a missing-information report and manual review checklist before filing.
| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-06 | ✗→✓ | ▲ Improved | 64% | 0% |
| case-10 | ✗→✓ | ▲ Improved | 332% | 0% |
| case-12 | ✗→✓ | ▲ Improved | 217% | 0% |
| case-14 | ✗→✓ | ▲ Improved | 236% | 0% |
| case-04 | ✓→✓ | ＝ Same ✓ | 379% | 0% |
将已完成的论文、附图和作者备注重构为接近可提交质量的中文发明专利草稿，同时始终保留明确的人工复核门槛。
除非用户明确要求其他语言，否则默认用中文输出。
默认语言风格要求如下，并适用于所有中间产物与最终产物：
本 skill 同时支持两类输入场景：一类是“论文转专利”改写，另一类是当材料中还包含发明交底、会议纪要或结构化作者备注时的更宽泛专利起草场景。
开始起草前，先读取 references/patent-structure-cn.md 和 references/paper-to-patent-mapping.md。
生成或修改权利要求前，先读取 references/claim-writing-guide.md。
输出接近终稿的内容或审核报告前，先读取 references/review-checklist-cn.md。
执行完整性或一致性检查前，先读取 references/compliance-check-cn.md。
当用户要求输出发明名称、发明人或申请人字段、申请元数据占位信息，或更完整的申请包结构时，先读取 references/front-matter-cn.md。
规划附图、图名或参考标号规则前，先读取 references/diagram-guidelines-cn.md。
将论文语言改写成专利语言前、准备放宽权利要求范围前、以及输出审核或质量判断前，先读取 references/rewrite-review-risks-cn.md。
严格按以下顺序执行，不要直接从论文跳到完整终稿。
尽量收集以下输入材料：
正式起草前，先输出一份简短的发明摘要，至少覆盖：
在这一阶段，必须明确给出专利类型建议：
当材料明显指向其他类型时，不要默认套用原有类型。
如果缺少下列任一信息，在起草终稿前必须先追问：
如果材料不完整，先输出缺失信息清单。不要虚构技术细节。
当用户要求的不只是纯改写，而是更像专利方案评估时，在权利要求起草前加入一轮轻量前置评估。
输出一份简短的研究与可专利性说明，至少包括：
除非用户已经提供正式检索结果，否则对新颖性、创造性和实用性的判断一律写成“初步风险判断”，不要写成最终法律结论。
对三性中的每一项，都标记为以下之一：
并说明判断依据。
除非用户明确提供了正式检索结果，或明确要求并完成了相关检索工作，否则不要声称已经完成正式现有技术检索。
在撰写权利要求和说明书前，先把论文重组为面向专利的结构。
始终先抽取并展示：
并且明确区分以下三类内容：
不要把实验指标、对比排名或学术结论直接当作保护范围本身。
离开映射阶段前，必须做一次闭环检查，将以下四项连起来：
如果这四部分之间不一致，先修正结构，再进入权利要求起草。
在进入正式起草阶段前，先展示发明摘要、前置评估说明（如果有）以及专利映射结果。
如果映射结果显示当前材料支撑不了目标保护范围，先暂停，并说明应该缩小范围、补充材料还是重新定义方案。
如果已经出现明显的新颖性或创造性风险，要在这一阶段直接指出，而不是拖到最后的复核部分。
先生成一份简要专利骨架，至少覆盖：
如果材料同时支撑方法保护和系统或装置保护，要在骨架阶段先标出这种双路径机会，再进入权利要求起草。
先起草权利要求，再扩写完整说明书。
从最有支撑、最有防御力的独立权利要求开始。
保护范围要分层设计，而不是一次性写死：
然后再补充从属权利要求，引入：
优先写清楚技术特征，不要用学术动机语言替代技术限定。除非效果确实对应具体技术手段，否则不要把优势或结果直接写成权利要求特征。
对于模型改进型方案，若用户已经明确模型名称，权利要求的重心应优先放在该模型本身及其关键改进结构上，而不是将全文重心放在泛化的“训练‑部署‑输出”流程描述上。
当发明的核心在于某一改进模型时，独立权利要求应优先围绕“基于什么基准模型构建何种改进模型、该模型包括哪些关键模块、这些模块之间如何配合实现检测或计数”进行组织；训练、剪枝、部署和结果输出等流程内容可以保留，但不应掩盖模型本体这一保护重点。
从属权利要求应优先围绕模型中的关键技术特征逐层展开，例如定向边界框表示方式、骨干网络结构、特征融合模块、检测头结构、剪枝策略、后处理方式等，使保护层次与模型结构层次保持一致。
如果材料只支撑方法类权利要求，要明确说清，不要凭空补出没有支撑的装置或系统结构。
在最终确定权利要求语言前，再做一次技术可行性检查：
在合适时，给出独立项组合策略，例如：
当用户要求将权利要求写得更接近“可提交草稿”时，还必须额外确认以下事项：
在扩写完整说明书前，先展示权利要求策略和第一版权利要求集合。
当保护宽度、实施形态拆分或保密边界仍不明确时，先征求用户反馈。
权利要求完成后，再用中文扩写完整说明书。
最终文本至少应包含：
写作风格应保持稳定的专利文风：
扩写说明书时，持续检查以下常见改写问题：
当输出包含“摘要”部分时，还必须额外确认以下事项：
当输出包含“具体实施方式”部分时，还必须额外确认以下事项：
即使附图不完整，也应先给出最小可用的附图说明，并明确标出所有假设。
如果材料支撑多个实施形态，按以下方式组织：
在最终定稿前，先识别支撑说明书所需的最小附图集合。
至少给出：
当用户需要方法流程图时，还应额外确认以下事项：
如果用户没有要求实际生成图片，就只输出文字版的附图规划和说明。
说明书骨架和附图规划就绪后，如果任务较大，或用户明显需要先审一轮结构，再暂停等待确认。
当用户需要时，可以输出以下前置信息的占位或草稿：
不要凭空填写法律事实，缺失信息一律用占位符表示。
最终输出始终以两个明确部分收尾：
在适用时，至少标出以下风险类别：
不要把草稿表述为法律终稿，也不要暗示其必然可以授权。
当用户要求输出审核式结果时，按 references/rewrite-review-risks-cn.md 的结构组织，至少包括：
在将输出称为“接近终稿”前，必须用 references/compliance-check-cn.md 做一次结构化自检。
至少核查以下内容：
如果用户希望得到更接近申请包的交付形式，则将结果组织为分阶段产物，而不是一个巨大的单体文本。
除非用户明确只要较小的中间产物，否则默认按以下顺序输出：
如果用户只想要更快的第一版，也仍然要保持“先权利要求、后说明书”的顺序。
在每次输出答案前，都必须额外执行一次语言风格检查，至少确认以下事项：
当输出包含“权利要求书”部分时，还必须额外确认以下事项：
当输出包含“技术领域”部分时，还必须额外确认以下事项：
当输出包含“发明内容”部分时，还必须额外确认以下事项：
当输出包含“摘要”部分时，在最终输出前还必须额外确认以下事项：
当输出包含“标题”部分时，还必须额外确认以下事项：
当用户需要分阶段交付时，按以下概念结构组织：
textpatent-application/ 01-intake/ 02-research/ 03-claims/ 04-specification/ 05-diagrams/ 06-front-matter/ 07-compliance/ 08-filing-package/
即使当前还没有真正落盘成文件，也要把它当作输出组织模型。
当前版本不执行以下任务：
.docx 文件scripts/ 目录为后续自动化能力预留，例如：
除非用户明确要求实现，否则不要自行假设这些工具已经存在。
Other measured skills in the registry, with their headline benchmark lift.