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.
.claude/skills/thomasmoreai-paper-to-cn-patent/SKILL.md| 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/ 目录为后续自动化能力预留,例如:
除非用户明确要求实现,否则不要自行假设这些工具已经存在。
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-01 | fail→fail | 32,458 | 35,835 | +10% | 1 | 1 | 0% | 5,847 | 12,102 | +107% | 0 | 0 | — |
case-02 | fail→fail | 36,013 | 34,930 | -3% | 1 | 1 | 0% | 6,269 | 12,096 | +93% | 0 | 0 | — |
case-03 | fail→fail | 36,318 | 50,857 | +40% | 1 | 1 | 0% | 6,253 | 12,079 | +93% | 0 | 0 | — |
case-04 | pass→pass | 7,948 | 7,636 | -4% | 1 | 1 | 0% | 1,390 | 6,665 | +379% | 0 | 0 | — |
case-05 | pass→pass | 18,127 | 9,440 | -48% | 1 | 1 | 0% | 2,540 | 7,207 | +184% | 0 | 0 | — |
case-06 | fail→pass | 26,141 | 10,203 | -61% | 1 | 1 | 0% | 4,520 | 7,425 | +64% | 0 | 0 | — |
case-07 | pass→pass | 16,364 | 15,385 | -6% | 1 | 1 | 0% | 2,587 | 8,253 | +219% | 0 | 0 | — |
case-08 | pass→pass | 16,707 | 16,737 | +0% | 1 | 1 | 0% | 2,681 | 8,455 | +215% | 0 | 0 | — |
case-09 | pass→pass | 14,105 | 9,663 | -31% | 1 | 1 | 0% | 2,127 | 7,503 | +253% | 0 | 0 | — |
case-10 | fail→pass | 11,785 | 13,355 | +13% | 1 | 1 | 0% | 1,847 | 7,970 | +332% | 0 | 0 | — |
case-11 | fail→fail | 23,128 | 30,347 | +31% | 1 | 1 | 0% | 3,933 | 11,566 | +194% | 0 | 0 | — |
case-12 | fail→pass | 17,663 | 13,632 | -23% | 1 | 1 | 0% | 2,525 | 8,012 | +217% | 0 | 0 | — |
case-13 | pass→pass | 16,184 | 16,066 | -1% | 1 | 1 | 0% | 2,493 | 8,244 | +231% | 0 | 0 | — |
case-14 | fail→pass | 16,490 | 15,465 | -6% | 1 | 1 | 0% | 2,449 | 8,224 | +236% | 0 | 0 | — |
case-15 | pass→pass | 13,651 | 11,701 | -14% | 1 | 1 | 0% | 2,154 | 7,660 | +256% | 0 | 0 | — |
case-16 | pass→pass | 11,436 | 8,306 | -27% | 1 | 1 | 0% | 1,540 | 7,042 | +357% | 0 | 0 | — |
case-17 | fail→fail | 18,967 | 15,607 | -18% | 1 | 1 | 0% | 2,848 | 8,202 | +188% | 0 | 0 | — |
case-18 | pass→pass | 16,848 | 17,102 | +2% | 1 | 1 | 0% | 2,827 | 8,750 | +210% | 0 | 0 | — |
case-19 | pass→pass | 10,621 | 11,299 | +6% | 1 | 1 | 0% | 1,825 | 7,786 | +327% | 0 | 0 | — |
case-20 | pass→pass | 13,212 | 14,359 | +9% | 1 | 1 | 0% | 2,125 | 8,198 | +286% | 0 | 0 | — |
case-21 | pass→pass | 16,673 | 12,881 | -23% | 1 | 1 | 0% | 2,258 | 7,764 | +244% | 0 | 0 | — |
case-22 | pass→pass | 16,514 | 10,610 | -36% | 1 | 1 | 0% | 2,499 | 7,530 | +201% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted. The headline lift of +18 percentage points is the difference between those two pass rates over the 22 comparable cases.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.