Skip to content
Conduit

skill

patent-writer

e5dese/patent-writercommunitylistedunreviewed

Set up

Skills are installed by placing their folder where your agent loads skills.

The download comes from github.com/e5dese/patent-writer itself, not from our server, so what you get is exactly what its author published.

Install instructions come from the README

Skills do not use an MCP config. Follow the steps in the README below.

README

synced Oct 26, 2026

patent-writer

An Agent Skill that turns a STEM technical scheme (paper draft, outline, or spoken idea) into a complete set of Chinese invention patent application documents: a formally-styled specification (.md + .docx), claims, and a method flowchart figure (.pptx).

面向理工科技术方案(论文草稿、大纲或口述思路)的专利撰写 Agent Skill,一站式产出符合中国发明专利申请规范的说明书正文(.md + .docx)、权利要求书,以及方法流程图附图(.pptx)。

Built for the Agent Skills standard — compatible with Claude Code, Comate, and other tools that support the SKILL.md format.

Why this exists

Writing a patent specification from a technical paper is repetitive and format-heavy: strict prose style, no Markdown, formulas standalone with symbol explanations, a fixed set of section headers, and a mandatory closing disclaimer sentence. On top of that, embedding formulas into Word/PowerPoint reliably (without character overlap, truncated superscripts, or mismatched font sizes) turns out to be surprisingly fiddly.

This skill encodes both the writing conventions and the formula-rendering pitfalls we hit while iterating on a real filing, so future runs don't have to rediscover them.

What it produces

Technical scheme (paper / outline / verbal description)
    ├─ Specification body (.md)              — formal Chinese prose, six mandatory sections
    ├─ Specification (.docx)                  — same content, laid out with editable
    │                                            Word formula objects + rendered formula images
    ├─ Claims (independent + dependent)       — filtered against a 5-point checklist so
    │                                            dependent claims aren't padded with low-value items
    └─ Method flowchart (.pptx)               — nested step boxes, formulas as images,
                                                 same visual scale as the .docx

Structure

patent-writer/
├── SKILL.md                       # entry point: workflow, conventions, troubleshooting table
├── references/
│   ├── style-guide.md              # specification prose rules + a "no fabricated content" policy
│   └── claims-guide.md             # dependent-claim filtering checklist
├── scripts/
│   ├── render_formulas.py          # batch-renders LaTeX/mathtext formulas to transparent PNGs
│   ├── omml_builder.py             # builds native, editable Word formula objects (OMML)
│   ├── fill_docx.py                # lays out the .md body into a styled .docx
│   └── draw_pptx.py                # generates the nested-box method flowchart
└── assets/
    └── example_flow_config.json    # sample flowchart config

Install

Claude Code (personal skill):

cp -r patent-writer ~/.claude/skills/patent-writer

Comate (personal skill):

cp -r patent-writer ~/.comate/skills/patent-writer

Either location works — the SKILL.md frontmatter (name + description) is what the agent reads to decide when to trigger the skill; nothing else is tool-specific.

Dependencies

The scripts are plain Python and need:

pip install python-docx python-pptx matplotlib Pillow

Usage

Once installed, just ask your agent naturally:

"Help me turn this paper into a patent specification." "Draft the claims for this method." "Draw the flowchart figure for this patent."

The agent will read SKILL.md, follow the three-stage workflow (spec body → formatted .docx → flowchart .pptx), and pull in references/ for the writing rules and scripts/ for formula rendering as needed. You don't need to call the scripts directly — the skill instructs the agent to invoke them with the right arguments — but they're also usable standalone if you want to run the pipeline manually.

Recommended model

This entire workflow — drafting the specification prose, spotting the fabricated-content issues, debugging the OMML formula rendering, and iterating on the flowchart layout — was developed and validated with Claude Sonnet 4.5. Long-form Chinese legal-document prose and multi-step visual layout debugging (formula overlap, superscript structure, image scaling) benefit from a strong reasoning model; lighter models are more likely to skip steps in the troubleshooting table or reintroduce issues that were already fixed (e.g. re-embedding a precomposed accented character instead of using the m_acc() helper). If you're running this skill with a different model, pay extra attention to the checklists in references/style-guide.md and the troubleshooting table in SKILL.md.

整个工作流——包括说明书正文撰写、发现无中生有的内容问题、调试 OMML 公式渲染、迭代流程图排版——都是在 Claude Sonnet 4.5 协作下开发和验证的。长篇中文法律文书写作与多步骤的可视化排版调试(公式重叠、上标结构、图片缩放)比较依赖模型的推理能力;能力较弱的模型更容易跳过排查表里的步骤,或者重新引入已经修复过的问题(例如重新塞入预组合重音字符,而不是使用 m_acc() 工具函数)。如果你用其他模型运行这个 skill,建议格外留意 references/style-guide.md 里的检查清单和 SKILL.md 里的常见问题排查表。

What makes the formula handling non-trivial

A few things that don't work the way you'd expect, all captured in SKILL.md's troubleshooting table:

  • Complex formulas as Word objects break silently. Hand-building OMML for nested superscripts (e.g. e^{Λk/(M-1)}) produces formula objects that render with empty superscripts in Word. The fix used here: render those as images instead, and reserve native OMML objects for simple inline symbols (ε_u, w_ij).
  • Precomposed accented Unicode characters overlap adjacent text. Characters like X̂ or à collide visually with a following parenthesis under Cambria Math. Fixed by decomposing them into proper OMML <m:acc> accent structures instead of embedding the precomposed glyph.
  • Formula image scale isn't just "pick a number." Getting formula images to look proportionate to body text requires converting pixel size → physical inches via the render DPI, then applying a scale factor tuned per target font size (docx vs. pptx use different scales).

Content integrity guardrails

references/style-guide.md also encodes a "no fabricated content" rule: no invented experimental numbers, no citing specific theoretical tools (e.g. a particular differential-privacy variant) unless the scheme actually derives them, and no claiming "rigorous formal proof" without the accompanying proof steps. These are easy mistakes to make when adapting from a paper's discussion section, and they're the kind of thing that unravels under scrutiny — so the skill flags them explicitly.

Scope

Currently tuned for Chinese invention patent specifications in STEM fields (the writing conventions, section structure, and mandatory closing sentence are specific to Chinese patent examination practice). The symbol-recognition regex in fill_docx.py defaults to a vocabulary common in differential-privacy / graph-neural-network papers — extending it for other subfields (documented inline) is a one-line change.

Acknowledgment

This skill's SKILL.md, reference documents, and scripts were drafted with the assistance of an AI coding agent (Kiro/Comate), based on lessons learned from iterating on a real patent filing. All content has been reviewed and validated against real usage, but as with any AI-assisted work, please review the writing-style rules and generated output for your own filing before relying on them as-is.

本项目的 SKILL.md、参考文档与脚本在编写过程中借助了 AI 编程智能体(Kiro/Comate)的协助,内容基于一次真实专利撰写过程中积累的经验。所有内容均经过实际使用验证,但如同所有 AI 辅助产出一样,建议你在正式提交前自行核对文风规则与生成结果。

License

Apache License 2.0. See LICENSE for the full text.

↑↓ navigate openesc close