A veteran core R&D engineer with eight years of experience may write all the code and carry the architecture—but still get stuck at the patent disclosure stage. The problem isn't writing ability; it's knowing how to mine patent points, run novelty searches, draw diagrams, fill Word templates, and draft claims that are broad yet defensible. That knowledge is scattered across patent agents' heads, examination guidelines, and hundreds of pages of training material. handsomestWei/patent-disclosure-skill tries to fill this gap with AI. It gained 571 stars in one day on GitHub Trending.
Project: https://github.com/handsomestWei/patent-disclosure-skill
The Problem It Solves
The first step of a Chinese patent application is the disclosure document—a technical explanation given to the patent agent describing what the invention is, what problem it solves, how, and what's novel. Engineers get stuck at:
1. Patent point mining: A feature might split into 3 patentable points, or none at all. 2. Prior-art search: CNIPA's search system has its own query syntax—Googling isn't enough. 3. Diagrams: Invention patents need mermaid flow diagrams; utility models need structural line drawings with part numbers; design patents need product contour drawings. 4. Word output: The deliverable is a formatted .docx with embedded images, not Markdown. 5. Iteration: Agents request corrections and claim revisions, each requiring tracked changes.
The skill connects all five steps end to end.
Core Capabilities
1. Type-Specific Templates
Chinese patents come in three types—invention, utility model, and design—each with a completely different disclosure structure. The skill auto-switches templates based on the declared type.
2. Project Scanning: Code to Patent Points
The skill scans your project directory—reading docs, code, .docx and .pptx files (converted to Markdown first)—to extract candidate patent points. Priority is documentation > code, mirroring examination logic: patents protect "technical solutions," not code implementations.
3. Prior-Art Search via CNIPA
A built-in crawler (tools/crawl/cnipa_epub_search.py) queries CNIPA's Chinese patent publication database for conflicts. If CNIPA search fails, it falls back to WebSearch—a sensible degradation given the system's occasional flakiness.
4. Automatic Diagram Generation
- Design line drawings: extracted from product images, or generated via image-to-image/text-to-image if none exist.
- Utility model structural drawings: outlines and part-number callouts generated per
structure_schema.parts, with sub-SVGs referenced by a master drawing. - CAD projections: isometric and multi-view views extracted from STEP/STP engineering models.
- Policy radar: searches recent CNIPA policies and examination trends into a reference list (off by default; doesn't change workflows without confirmation).
- Response drafting: historical office actions and responses are anonymized, stored, and tagged by legal provision/defect; new notifications are matched against this history to draft responses, with optional local vector models for semantic retrieval—essentially a self-built RAG knowledge base.
- Drafts only: The README states outputs require human review before filing; claim wording and scope still need an agent's judgment.
- CAD limits: STEP/STP parsing is skipped by default ("don't interrupt writing; ask after the disclosure is saved")—format variance across CAD tools makes parsing fragile.
- Policy compliance: The policy radar deliberately doesn't auto-change workflows—humans keep decision authority.
5. Obsidian Knowledge Base
Beyond writing disclosures, the skill extracts claim trees, glossaries, and feature-description-drawing mappings from published patents into an Obsidian vault. Over dozens of patents, bidirectional links accumulate into a personal patent intelligence layer for comparison, family analysis, and technology-roadmap mapping.
6. Policy Radar + Office-Action Responses
Why It Matters
The "last mile" problem: AI coding assistants write code, but converting technical work into compliant professional documents (disclosures, design docs, audit reports, bid documents) has been underserved. Engineers know the tech but not the format; agents know the format but not the tech.
Vertical depth: The skill encodes knowledge that normally requires an agent + engineer + CAD drafter—three patent types, CNIPA integration, CAD parsing, patent-compliant line art, and awareness that guideline changes affect disclosure writing.
Obsidian as knowledge layer: Bidirectional links + graph views suit patents' terminology-dense, cross-referential nature.
Caveats
The Bigger Picture
The project signals vertical AI skills expanding from "writing code" to "writing professional documents." Code is structured and compiler/test-verifiable; professional documents are not—errors surface only at examination or bid results. That raises the bar: skills must encode domain knowledge, format norms, and compliance requirements as modes (invention/utility/design/policy/responses), each with its own toolchain. Any field where "engineers do the work but can't write the deliverables" could spawn a similar vertical skill.
Best for: engineers writing disclosures, patent agents, and corporate IP teams. Difficulty: moderate (patent basics required; Obsidian optional but recommended).