handsomestWei/patent-disclosure-skill: A Chinese Patent Skill for Disclosure Drafting and Reading

Who handsomestWei/patent-disclosure-skill is actually for

The README opens with a complaint rather than a feature list: engineers write the code and carry the design, then stall at the disclosure because they do not know which parts of their work are patentable. That framing tells you the target user. This is not a tool for a patent attorney running a prosecution practice; it is a tool for the person who has design documents and source code in hand and needs to get something filable out the other end.

The scope is Chinese practice. The README names 发明, 实用新型 and 外观设计 (invention, utility model, design), and the search sub-skill targets 公布公告, the CNIPA publication and announcement system. Nothing in the repository describes USPTO, EPO or PCT workflows, and the requirements file points at epub.cnipa.gov.cn for crawling. If your filings are not Chinese, the document templates and the retrieval path are both aimed somewhere else.

Second audience: readers. The patent-reader sub-skill takes a publication number or a PDF and produces plain-language notes plus a graph, pushed into Obsidian. The README's stated goal is a private, growing patent knowledge base where claims, terms and figures cross-link. That is a different job from drafting, and the repository treats it as a separate skill rather than a mode of the drafting one.

Eight sub-skills, one AgentSkills entry point

The repository is not a single program. It is a set of eight sub-skills under skills/, each with its own README, wired together by SKILL.md at the repository root. The sub-skills are patent-disclosure (disclosure drafting), patent-application (claims, specification, abstract, drawings), patent-docket (a role-play workflow where a disclosure engineer and a patent agent plan multiple rounds), patent-reader (plain-language reading), patent-map (maps and dashboards), patent-oa (office action response), patent-search (bibliographic search) and patent-exam-policy (policy briefings).

Each sub-skill has a trigger phrase. The README lists them: 「交底书」 for disclosure, 「申请文件」 or 「申请底稿」 for application documents, 「交底申请一起做」 or 「从零出交底和申请」 for the docket workflow, 「读专利」 for reading, 「专利地图」 or 「案例地图」 for maps, 「审查答复」 or 「审查意见」 for office actions, 「著录检索」 for search, and 「政策简报」 or 「政策雷达」 for policy. You do not invoke a CLI; you speak a trigger and the agent loads the matching skill.

That architecture is the main design decision, and it has a cost. There is no single command that runs the whole pipeline. The docket sub-skill is the closest thing to an orchestrator: the README describes it as autonomously planning a multi-round workflow and asking for missing facts rather than inventing them. Everything else is invoked piecewise, and the quality of the handoff between skills depends on the agent runtime you are using, not on this repository.

Installing the Python toolchain behind the skills

The README points to INSTALL.md for full instructions, so treat that file as authoritative. What the repository does give you directly is requirements.txt, and its comments map each dependency to the tool that needs it: python-docx for the Markdown-to-Word converter, latex2mathml for editable Word equations, PyYAML for the formula plan and paradigms.yaml, playwright for Mermaid rendering and the CNIPA crawl, mammoth for reading .docx back in, and python-pptx for reading .pptx. The badge in the README states Python 3.9 or newer.

Install the base set from the repository root:

pip install -r requirements.txt

Several capabilities are optional and gated behind extra installs. Formula rendering to PNG is only used when the OMML path fails and the user agrees; the requirements file notes it pulls in matplotlib and roughly 100MB including numpy. The CNIPA crawl needs Playwright and a system Chrome or Edge. The requirements file gives a probe command to check that:

python skills/patent-disclosure/tools/browser.py --probe

If the probe finds no system browser, the file says to install Chromium with `python -m playwright install chromium`. There is also a separate CAD path for STEP files: `python skills/patent-disclosure/tools/cad_venv.py` builds an environment with CadQuery, and the requirements file pins that environment to Python 3.10 through 3.12, narrower than the 3.9+ the README advertises for the rest.

For a first real use, the concrete entry point documented in the repository is the Markdown-to-Word converter, which is what turns a drafted disclosure into an editable file:

python skills/patent-disclosure/tools/md_to_docx.py -i a.md -o a.docx

Add `--math-render` if you want formulas rendered as images when the MathML path fails. The README's screenshots show timestamped disclosure files and a mermaid diagram directory under outputs/, and the CAD example writes to `outputs/case/cad_views`, so expect generated artifacts in an outputs tree rather than in place.

Where the skill stops and the agent takes over

The most honest limitation is structural: this repository is a set of skill definitions plus Python helpers, not an application. The drafting, claim writing and reading are performed by whatever agent loads the skill. The Python tools handle deterministic conversions (docx, pptx, Markdown, Mermaid, formulas, CAD views, browser automation), and the prose work is delegated.

That means the output quality is not a property of this repository. It is a property of your model, your context window, and how much project material you feed in. The README's own pitch for the docket sub-skill is that it asks for missing facts instead of fabricating them, which is a prompt-level commitment, not an enforced one. There is no validation layer in the repository that checks a draft disclosure against the material it came from.

A second limitation is the CNIPA dependency. The patent-search and policy sub-skills reach the national intellectual property administration's site through Playwright. That is a browser automation path against a government website. When the site changes markup, the crawl breaks, and no release in the repository is listed to fall back on. The requirements file treats the browser as optional and probes for a system install, which suggests the authors expect this path to be environment-sensitive.

Third, the repository does not document rollback. The README shows iterative versions with timestamps and a conversation record for revisions, but there is no described mechanism for reverting a disclosure to an earlier state beyond keeping the older timestamped file. If you need auditable version history, you are supplying it.

How it differs from generic patent drafting tools

The obvious alternative is a general-purpose patent drafting product, and the difference is where the work happens. A conventional drafting tool gives you a form: fields for title, technical field, background, embodiments, claims. You fill them. This repository inverts that. You hand over design documents, code or a product image, and the skill is supposed to mine the patentable points first, then check prior art, then write. The README's own framing is that the hard part is 专利点怎么挖, not filling in a template.

The second difference is the reading side. Most drafting tools stop at filing. Here, patent-reader converts a publication into notes and pushes them into an Obsidian vault, and patent-map turns the accumulated vault into semantic terrain, applicant quadrants, family and citation networks, and a technology-effect matrix, opened in a browser and run locally. That is a knowledge-management layer, not a drafting layer, and it is the part of the repository least served by existing patent software.

The third difference is policy tracking. patent-exam-policy reads recent CNIPA announcements and reports which disclosure techniques or application formats in the skill set may have gone stale. No drafting tool does this, because drafting tools do not own the drafting heuristics.

Maintenance, licence and upgrade cost

The last push to the default branch was on 2026-09-20, one day before this review. The repository is not archived. That is a snapshot, not a promise, and the README does not publish a support policy, a compatibility matrix or a deprecation schedule.

The upgrade cost sits mostly in the Python side. requirements.txt pins floors rather than ceilings: python-docx>=1.1.0, latex2mathml>=3.77.0, PyYAML>=6.0, playwright>=1.40.0, mammoth>=1.6.0, python-pptx>=0.6.21. An unpinned upper bound means a major release of any of these can move under you, and the Playwright dependency is the one most likely to break, because browser automation tracks browser versions. The CAD path is worse: CadQuery runs in its own environment built by cad_venv.py and the requirements file restricts it to Python 3.10 through 3.12 while the rest of the project accepts 3.9+. If you need STEP views, your interpreter choice is constrained by that sub-path.

The licence is MIT, stated in the README badge and the LICENSE file. MIT permits commercial use and modification with attribution and no warranty. That is the whole of what the repository says. It says nothing about the legal status of generated documents, the accuracy of retrieved prior art, or whether a disclosure produced this way is adequate for filing. Those are questions for a qualified practitioner in your jurisdiction, and the licence text does not address them.

Editorial conclusion

Adopt it if you are an engineer or patent-adjacent worker producing Chinese invention, utility model or design disclosures and you already have an agent runtime that can load AgentSkills. Do not adopt it if you file in English-language jurisdictions, need a docketing system of record, or expect the repository to hand you a validated legal output. Before relying on it, open SKILL.md, INSTALL.md and the individual skills/*/README.md files, and run the requirements.txt install plus the browser probe to confirm the CNIPA path works on your machine.

Frequently asked questions

Official sources

1. handsomestWei/patent-disclosure-skill on GitHub
2. Issues
3. License: MIT
4. Project website
5. README