An engineer with eight years of core R&D experience wrote the code and carried the architecture — but got stuck every time at the patent disclosure stage.
Not because they can't write — but because they don't know how to mine patentable points. A genuinely clever caching strategy ends up described as "a caching method," so bland an examiner would reject it outright. How do you do a prior-art search? How do you draw the diagrams? How do you fill the Word template? How do you write claims that are broad enough to protect you but not so broad that prior art kills them?
The answers to these questions are scattered inside patent agents' heads, examination guidelines, and hundreds of pages of training material. Engineers don't have time to learn this; patent agents don't have time to learn the engineer's technical details.
handsomestWei/patent-disclosure-skill tries to fill this gap with AI. It gained 571 stars on GitHub Trending in a single day.
What Problem It Solves
The first step of a Chinese patent application is writing a "disclosure document" (交底书) — a technical document for the patent agent explaining what the invention is, what problem it solves, how it solves it, and what's novel about it.
It sounds simple, but it stumps countless engineers:
1. Patent point mining: You built a system, but don't know which parts are worth patenting. One feature might split into 3 patent points — or none at all. 2. Prior-art search: You need to check whether similar patents exist. The CNIPA search system has its own query syntax — it's not a Google search. 3. Diagrams: Disclosures require structural diagrams. Invention patents use mermaid flowcharts, utility models need structural line drawings, design patents need product outline drawings — three completely different diagram types. 4. Word output: The final deliverable is a .docx file, not Markdown. Templates, embedded images, part number callouts. 5. Iteration: Writing the disclosure isn't the end. The agent requests supplementary materials, corrections, claim revisions. Every revision needs a paper trail.
This skill wires all five steps together.
Core Capabilities
1. Separate Templates for Three Patent Types
Chinese patents come in three types: invention, utility model, and design. Their disclosure structures are completely different:
- Invention: methods/systems/algorithm flows, with mermaid diagrams
- Utility model: shapes, construction, connections and assembly — structural line drawings with part number callouts
- Design: shape, pattern, color — product line drawings
- Design line drawings: automatically extract product silhouettes from product images. If you have an acceptable line drawing it uses that; otherwise it generates one via image-to-image or text-to-image.
- Utility model structural drawings: automatically generate outlines and part number callouts from structure diagrams. Sub-SVGs are written per
structure_schema.parts, referenced by the master drawing. - CAD 3D projections: automatically extract isometric and multi-view projections from STEP/STP engineering models.
- Policy radar: searches the web for recent CNIPA policies and examination trends, compiled into a reference list. When examination guidelines change, disclosure writing may need to change too.
- Office action support: historical office actions and responses are anonymized and stored, tagged by legal provision and defect type. When a new office action arrives, filter and search past experience by tags to draft responses. Optionally enables a local vector model for semantic retrieval — essentially building your own RAG knowledge base.
- Technical review documents
- System design documents
- Security audit reports
- Technical proposal bid documents
- Knows the differences between the three patent types and their respective templates
- Connects to the CNIPA search system
- Extracts engineering views from CAD files
- Generates patent-compliant line drawings
- Understands that examination guideline changes affect how disclosures should be written
The skill switches templates automatically based on what you say. Say "utility model disclosure" and it uses the utility model template, not an invention-style flowchart.
2. Project Scanning: From Code to Patent Points
This is the most interesting part. The skill scans your project directory — reading docs, code, and .docx/.pptx files (converted to Markdown first) — and extracts technical points potentially worth patenting.
The scanning priority is: documentation > code. If you have design docs it reads those first; only without docs does it read code. This matches patent examination logic — patents protect the "technical solution," not the "code implementation," and design docs are closer to the abstraction level of a technical solution.
3. Prior-Art Search: Connected to CNIPA
The skill ships with a crawler for the CNIPA (China National Intellectual Property Administration) patent publication database (tools/crawl/cnipa_epub_search.py). It searches existing patents using your mined patent points to check for collisions.
If the CNIPA search fails or errors out, it degrades to WebSearch. This fallback is practical — the CNIPA system occasionally misbehaves, and it shouldn't be a single point of failure.
4. Diagrams: Automatic Line Drawing
This feature is hardcore:
You don't need to draw by hand — the skill generates patent-compliant figures from your design materials.
5. Obsidian Knowledge Base: Reading Patents Deeply
Beyond writing disclosures, the skill can also "read patents" — extracting claim trees, glossaries, and feature-specification-figure mappings from published patents into an Obsidian knowledge base.
The value here is compounding: every patent read enriches the backlinks between terms and claims. After dozens of patents, your Obsidian vault becomes a personal patent intelligence layer — usable for patent comparison, family analysis, and technology roadmap mapping.
6. Policy Radar + Office Action Support
Two advanced features:
Why This Project Matters
The "Last Mile" Problem
AI coding assistants can already write code, but "converting technical work into deliverable professional documents" has long lacked tooling. Patent disclosures are just one scenario — similar needs include:
These documents share a common trait: they require domain knowledge + format standards + multi-round iteration. Engineers can do the technical work but can't write the documents; agents can write documents but don't understand the technology. patent-disclosure-skill tries to cover both ends with AI.
Depth of a Vertical Skill
Unlike general AI assistants, this skill's depth shows in that it:
Obsidian as the Knowledge Layer
Choosing Obsidian as the knowledge base carrier is a smart decision. Obsidian's backlinks + graph + Canvas naturally fit patents — a domain that's terminology-dense, cross-reference-heavy, and needs relationship visualization.
A patent's claim tree, glossary, and feature mapping become notes; multiple patents connect via backlinks. As the vault thickens, you can do patent comparison, technology roadmap mapping, and difference scanning — moving from "understanding" to "using."
Some Sober Observations
Output Is Still a Draft
The README explicitly states: "output is a draft; it must be human-reviewed before filing." AI can generate structure and a first draft, but fine-grained work like claim wording and scope definition still needs a patent agent's review.
CAD Parsing Limitations
The skill doesn't parse STEP/STP files by default — when encountered, "writing proceeds without interruption; questions are deferred until after the disclosure is saved." This shows CAD parsing remains a hard problem: STEP file formats vary widely across CAD software, and parsing stability is questionable.
Policy Compliance
The "policy radar" searches the web for CNIPA developments, but "off by default; before you confirm, it won't change disclosure/interpretation workflows on its own." This design is sound — policy changes shouldn't automatically alter workflows; humans must retain decision authority.
The Bigger Picture
patent-disclosure-skill represents a trend: vertical skills for AI coding assistants are expanding from "writing code" to "writing professional documents."
Code is structured, validated by compilers, and testable. Professional documents (patent disclosures, audit reports, bid documents) are unstructured, have no compiler validation, and errors only surface at examination or bidding time.
This means the bar for vertical skills is higher — you need not just code knowledge, but domain knowledge, format standards, and compliance requirements. patent-disclosure-skill's approach is to encode domain knowledge as skill "modes" (invention/utility model/design/policy/office actions), each with its own toolchain and templates.
This pattern may be replicated in other scenarios requiring the intersection of "technology + professional documents." Any domain where "engineers do the work but can't write the deliverable documents" could grow a similar vertical skill.
---
Project URL: https://github.com/handsomestWei/patent-disclosure-skill
Who it's for: Engineers who need to write patent disclosures, patent agents, corporate IP teams
Difficulty: Medium (requires basic patent knowledge + Obsidian optional but recommended)