Turn Claude Code Into a Patent Drafting Assistant: A Hands-On Guide to the China Patent Skill
Patent paperwork is the one part of engineering nobody trains you for. This open-source skill pack, the China Patent skill, hands that work to your AI agent. Once installed in Claude Code or Cursor, it digs patentable points out of your project materials, writes disclosure documents with block diagrams, converts them into editable Word files, searches CNIPA’s publication database, and turns published patents into plain-language notes filed in a personal Obsidian knowledge base. It follows the AgentSkills layout, ships under the MIT license, and organizes everything through eight sub-skills.
This guide walks the setup in the order you would actually hit it. Three questions matter most: which dependencies are mandatory, which ones you should hold off on installing, and which features only trigger when you name them out loud.
What does the China Patent skill actually do?
It splits the Chinese patent workflow, from disclosure to office-action response, into eight sub-skills, covering both ends of the problem: engineers who cannot write the documents, and readers who cannot parse published patents.
That “must be named” column is the part newcomers trip over. Five features (application documents, case assembly, patent maps, office-action support, policy briefs) enter only when you say the trigger words yourself. The agent will not upgrade your workflow on its own. Ask it to read one patent and it will not quietly open the map. Ask it to write a disclosure and the prior-art check uses the disclosure pack’s own lightweight search, one keyword per page with ten results per page in publication mode. It does not call the search pack, and the search pack’s results can never stand in for a disclosure prior-art check either way. The boundaries are hard, which is exactly why accidental triggers are rare.
Portfolio building goes through naming too. The docs call it a fence, a protective 1+N layout, or a family tree, and the precondition is a finalized first disclosure. The flow runs decomposition, breakthrough, matrix, then a project statement recorded in 专利布局.md. Until you confirm that statement, the skill will not mass-produce follow-on disclosures.
Two global conventions round this out. Without an explicit type, a disclosure defaults to invention. And every output lands in your workspace under outputs/, sorted by type: readings in outputs/patent_reader/, searches in outputs/patent-search/, case files in outputs/docket/, application files in outputs/patent-application/. When calling scripts, run from the workspace root. Nothing gets written into the skill’s install directory or tmp/.
A finalized disclosure looks like this, first version written to disk once, later revisions coexisting as timestamped files with the conversation log attached:


Why build a patent skill for AI coding agents?
Because the README names two real pains, and both come from lived experience rather than market research. The project starts with one line from the author:
“
“Years of core R&D, and my name has never once appeared in the inventor field of a patent.”
The unpacking is more concrete. You wrote the code. You carried the design. Then the disclosure stalls on three practical questions: how do I mine the patentable points, how do I write the prior-art search, how do I get diagrams and a Word file out in one pass. The skill closes that gap. It reads structure diagrams and design drawings, sorts the appliable points out of project material, and handles searching, desensitizing, drafting, and versioned iteration, so the person who did the work can put their contribution into a submittable document.
The other end is reading. Published patents wrap simple ideas in twisting claims and dense jargon, with the implementation context scattered between the description and the figures. The reader sub-skill turns a single patent into plain notes and a graph, stored in Obsidian. Read enough patents and the linked notes grow into a private knowledge base where claims, terms, clues, and figures reference each other. Once the library is thick, you can run comparisons on top of it: family对照, technology-route mapping, difference scanning. Reading turns into using.
My own take: putting both jobs in one tool holds up. The publications you retrieve for a prior-art check are also raw material for the reading library, so writing and reading share one infrastructure. Shuttling between two separate tools for that would get old fast.
How do you install it in Claude Code or Cursor?
Clone the complete repository into the directory each tool scans. Both understand the AgentSkills convention: the repo root is the skill root, containing SKILL.md, and that is enough for discovery.
For Claude Code, install at the root of your project’s git repository:
mkdir -p .claude/skills
git clone <repo-url> .claude/skills/patent-disclosure-skill
Copying from a local path into .claude/skills/patent-disclosure-skill works too.
Cursor distinguishes global and per-project installs. Global means every project can use it:
macOS / Linux:
mkdir -p ~/.cursor/skills
git clone <repo-url> ~/.cursor/skills/patent-disclosure-skill
Windows (PowerShell):
New-Item -ItemType Directory -Force -Path "$env:USERPROFILE\.cursor\skills"
git clone <repo-url> "$env:USERPROFILE\.cursor\skills\patent-disclosure-skill"
For the current project only, place it at <project-root>/.cursor/skills/patent-disclosure-skill/.
Three things break Cursor installs in practice:
-
Copy the full repository, including every skills/patent-*subpackage. A single folder is not enough. -
The namefield insideSKILL.mdmust match the folder name. Both arepatent-disclosure-skillhere. -
Restart Cursor, then check Settings → Rules to confirm discovery, or type /in the Agent input and pick the skill.
Worth knowing: Cursor also scans ~/.claude/skills/ and project-level .claude/skills/, so an existing Claude Code install will likely be picked up as is. If you would rather move nothing, open the repo root directly as your Cursor workspace. Step-by-step instructions for that mode live in the per-feature prompts/ directories.
One path rule applies everywhere. Commands in the docs are relative to the skill repo root, the directory holding the top-level SKILL.md, for example python skills/patent-disclosure/tools/image_gen.py. When your workspace is not that repo, locate the skill install directory first and prepend it. Do not lean on vendor-specific environment variables. If you copy a single subpackage out on its own, use python tools/… inside that package instead.
How much setup does the default invention workflow need?
Three things: Python 3.9 or newer, one requirements file, and a local Chrome or Edge. That covers finalization with rendered diagrams and CNIPA searching. No Node, no npm, no mmdc.
Install the dependencies (this includes python-docx and playwright):
pip install -r requirements.txt
Then probe the browser:
python skills/patent-disclosure/tools/browser.py --probe
An ok=true result means you can finalize with images and run CNIPA searches. If the probe complains about a missing Playwright package, rerun the pip command above. Only when the machine has neither Chrome nor Edge do you need python -m playwright install chromium, and that is a one-time install per machine.
Default outputs for an invention disclosure: a .md plus a .docx, PNG renders for the 3.2 / 3.4 block diagrams, and Step 5 preferring the CNIPA search.
No browser available? There is a fallback. The invention disclosure can ship as Markdown first, with mermaid fences preserved in the text. Word diagrams will show as code blocks for the moment. Once a browser is in place, rerun mermaid_render.py and the images render.
Formulas travel into Word as OMML, handled by latex2mathml, already listed in requirements.txt. Here is the rule people break: do not install matplotlib for a default disclosure. Only when finalization prints omml_text_fallback on stderr and you answer yes, run:
pip install matplotlib
python skills/patent-disclosure/tools/md_to_docx.py -i final.md -o final.docx --base-dir final-dir --math-render
PDFs in the scan directory call for one extra file:
pip install -r skills/patent-disclosure/tools/requirements-pdf.txt
Utility model and design finalizations follow each type’s own disclosure_builder.md: the form-filling step produces structure_schema or appearance_schema plus a figure_plan.yaml, and the draft embeds only the figures on that list (structure views or design views; the docx is recommended for utility models, optional for designs). Even when you skip the invention mermaid flow, installing requirements.txt is still sensible, since Word/PPT scanning and docx generation rely on it.
The lightest possible case: if you hand-write Markdown in an editor and never run repo scripts, you need no Python at all. Details live in skills/patent-disclosure/tools/README.md.
After reading through the dependency list, my impression is that this repo is strict about when each install happens. matplotlib, a heavyweight, sits on a fallback path. CadQuery is isolated (more below). First-install time stays low, and throwing every optional package in at once is more likely to make a mess than to save time.
Can you skip the line drawings for utility models and designs?
Not by default. Lineart is a mandatory step before drafting, and the flow does not pause to ask. It runs unless you set PATENT_SKILL_SKIP_LINEART=1 or explicitly say you do not want line drawings. CAD projections do not count as lineart and must not enter the documents.
Four commands, in order ({case} is your case directory):
python skills/patent-disclosure/tools/image_gen.py --case-dir outputs/{case}
python skills/patent-disclosure/tools/design_lineart_gate.py --case-dir outputs/{case} --prepare-jobs
python skills/patent-disclosure/tools/structure_lineart_gate.py --case-dir outputs/{case} --prepare-jobs
python skills/patent-disclosure/tools/structure_lineart_compose.py --case-dir outputs/{case}
The principle: plan first, draw second. Structure lineart writes sub-SVGs per the parts list, composes them into a full sheet, then overlays part-number leader lines. Inventing part numbers is forbidden.
Results in practice:



CAD/STEP support is a separate switch, off by default. When a scan finds .step or .stp files, drafting does not stop. After the disclosure md and docx are written to disk, the agent asks whether you want STEP parsing enabled. No CadQuery gets installed before you confirm. If you only have native CAD like SolidWorks and no STEP export, the delivery reply will remind you to export a neutral format.
Once confirmed, probe first, then bootstrap:
python skills/patent-disclosure/tools/cad_venv.py
python skills/patent-disclosure/tools/bootstrap_cad_venv.py
python skills/patent-disclosure/tools/run_step_to_views.py --enable-step-parse -i model.step -o outputs/{case}/cad_views
CadQuery lives only inside an isolated venv running Python 3.10 through 3.12. If your machine already runs 3.11 or 3.12, there is no need to install 3.10 alongside. Without system Cairo, the pipeline keeps SVG output and screenshots PNGs through the existing Playwright headless browser. CAD drawing never touches matplotlib. This whole dependency set is independent of the main requirements.txt, so removing it leaves the main flow untouched.
What should you know before searching CNIPA publications?
Installing the crawler is the easy part. Two behaviors deserve your attention before you trust any results: how “complete” gets reported, and how Windows terminals behave.
Install the crawler alone, without the full main dependency set, like this:
pip install -r skills/patent-disclosure/tools/crawl/requirements-cnipa.txt
python skills/patent-disclosure/tools/browser.py --probe
# Only if the probe shows no Chrome/Edge and no bundled Chromium:
# python -m playwright install chromium
The disclosure lightweight search runs one keyword per page:
python skills/patent-disclosure/tools/crawl/cnipa_epub_search.py --type utility_model 卡扣
(卡扣 means “snap-fit”; CNIPA’s database is Chinese-language, so search terms should be too.)
The bibliographic search defaults to the max_pages setting in config.yaml. Change it in conversation or via --max-pages:
python skills/patent-search/tools/cnipa_search.py --inventor "Inventor Name" \
--applicant "Applicant One" \
--applicant "Applicant Two" \
--type all
Results land in outputs/patent-search/SEARCH-*.md, formatted by emit_search_report.py, with the machine-readable prefixes EPUB_SEARCH_MD and EPUB_SEARCH_JSON printed alongside.
The first trap sits right here: only complete: true means the crawl reached the last page. Exit code 3 signals partial results, and claiming “all” on that basis is forbidden. Normal queries should not default to --complete. In a patent context this constraint carries real weight; treating partial results as complete wrecks the reliability of any prior-art conclusion built on them.
The second trap is the Windows terminal. The finalization and search scripts set stdout and stderr to UTF-8 and pass PYTHONUTF8=1 to subprocesses. Judge success by exactly two signals: the exit code, and the machine-readable prefixes (EPUB_HITS_JSON:, EPUB_SEARCH_JSON:, PROBE:, MERMAID:, DOCX:, MATH:). Chinese text on stderr, or PowerShell raising NativeCommandError, does not mean failure. There is no need to run chcp 65001 first. If output still looks garbled, set PYTHONUTF8=1, and keep JSON out of the error stream by not using 2>&1.
I have watched PowerShell paint red NativeCommandError text across the screen and assumed the script died. The exit code was 0 and the files had landed fine. This is the section to read before your first run; it saves a lot of pointless reruns.
On dependencies: playwright is already in the root requirements.txt, so a full main install covers searching without a separate pip run. The requirements-cnipa.txt file exists only for crawler-only setups. If nothing is installed or the probe fails, Step 5 of the disclosure flow degrades gracefully to WebSearch, say Google Scholar.
Why won’t the application, docket, or map features respond?
They are gated behind explicit named triggers, and several carry preconditions. Application files, case assembly, patent maps, office-action support, and policy briefs all wait for you to say the words. Application files additionally require a disclosure directory. Here is what each one needs.
Application documents
Rewrites an existing disclosure into claims, description, abstract, and black-and-white figures. Missing schema, lineart, or the disclosure itself stops the run and points you back to the disclosure skill. Content that cannot be pinned down goes into an issue list rather than blocking the full document set, and “confirm after delivery” messages summarize that list. Revising existing output saves a new version. No new dependencies are needed (PyYAML plus the existing python-docx and playwright), and TIFF is out of scope.
python skills/patent-application/tools/material_gate.py --case-dir outputs/{case}
python skills/patent-application/tools/render_invention_figures.py \
--plan outputs/patent-application/{case}/figures/invention_figures.yaml \
--out-dir outputs/patent-application/{case}/figures
python skills/patent-application/tools/audit_claims.py outputs/patent-application/{case}/claims.md
python skills/patent-application/tools/check_support.py --dir outputs/patent-application/{case}
python skills/patent-application/tools/emit_application_docx.py --dir outputs/patent-application/{case}
A gate exit code of 2 means materials are missing. Go back to the disclosure skill and fill the gaps first.
Case assembly (docket)
Strings disclosure and application into one pass: documents get written from the material the inventor or engineer supplies, and gaps on the issue list allow at most three rounds of back-and-forth. Missing technical facts stop the process for a question; nothing gets invented. The docket package only keeps records and dispatches work. The actual text still comes from the disclosure and application packs. During dispatch it reads their SKILL.md files but never calls their tools/ from inside the docket package. Responsibility stays clean, so one package never fabricates content for another. The only dependency is root-level PyYAML.
python skills/patent-docket/tools/init_docket.py --case-id {case-slug} --mode from_zero
python skills/patent-docket/tools/validate_docket.py --yaml outputs/docket/{case-slug}/docket.yaml
python skills/patent-docket/tools/emit_tracker.py --yaml outputs/docket/{case-slug}/docket.yaml
Output lands in outputs/docket/{case}/ (docket.yaml + TRACKER.md), with machine prefixes DOCKET_DIR:, DOCKET_YAML:, DOCKET_OK:, DOCKET_ERROR:.
Office-action support
Triggered explicitly by “office action”, case ingest, or /oa. A thin library triggers guidance toward ingesting or distilling cases first. Configuration and the vector store default to the OS documents directory at {Documents}/patent-disclosure-skill/oa/, overridable with PATENT_OA_HOME. Zhipu’s embedding-3 comes recommended; DashScope, MiniMax, local models, and OpenAI also work (config.py set --preset …).
pip install -r skills/patent-oa/tools/requirements-oa.txt
# Example: Zhipu
# Environment variable ZHIPUAI_API_KEY=…
python skills/patent-oa/tools/config.py recommend
python skills/patent-oa/tools/config.py set --preset zhipu
python skills/patent-oa/tools/ingest_case.py -i path/to/case.md
python skills/patent-oa/tools/refresh_vault.py # refreshes the oa index / Bases / linked Canvas
python skills/patent-oa/tools/search_cases.py --query "inventive step distinguishing features" --defect inventiveness --top-k 5
# The response-text Word file is generated only after you confirm a draft
# python skills/patent-oa/tools/emit_opinion_docx.py -i outputs/oa/case/response_timestamp.md
Obsidian case files land in the vault at oa/cases/history/, with pending/, drafts/, and playbooks/ alongside. Dependencies are independent of the main requirements.txt.
Policy briefs and the patent map
The policy brief reads recent announcements from CNIPA’s official site and produces a plain-language summary, flagging which disclosure techniques or application templates inside the skill may be going stale as examination practice shifts. Evolving the skill itself is a side path; without a named trigger, nothing outside the disclosure pack gets modified.
The patent map requires a vault with interpreted cases already stored. It also must be named, and reading one patent will never auto-open it.
Is the Obsidian vault optional?
Yes, but the experience drops a notch. Without a vault, interpretations and intermediate artifacts still write to the workspace at outputs/patent_reader/. What you lose is the index, the Canvas knowledge graph, the term network, graph color coding, and publication-clue annotations. The docs phrase it as “strongly recommended to install and configure Obsidian”.
Run the probe to locate a vault:
python skills/patent-reader/tools/vault/check_obsidian_env.py
# Auto-accept the only / currently open vault:
python skills/patent-reader/tools/vault/check_obsidian_env.py --auto-accept
# Set manually and persist (adds a Windows user environment variable):
python skills/patent-reader/tools/vault/check_obsidian_env.py --set "C:\Users\you\Documents\Obsidian Vault" --setx
Session-only variables work too:
$env:PATENT_READER_OBSIDIAN_VAULT = "D:\Obsidian\YourVault"
# Optional: in-vault directory, default Research/Patents
$env:PATENT_READER_PAPERS_DIR = "Research/Patents"
$env:PATENT_READER_GLOSSARY_DIR = "Research/术语"
Two dependency files, one per feature: pymupdf handles PDFs for the reader, and fastembed (no PyTorch included) powers the patent map’s semantic terrain:
pip install -r skills/patent-reader/tools/requirements.txt
pip install -r skills/patent-map/tools/requirements.txt # optional: patent-map semantic terrain
The patent map’s vector model and its accelerated copy default to the documents directory at {Documents}/patent-disclosure-skill/patent-map/ (a sibling of oa, overridable with PATENT_MAP_HOME). Do not download it into the workspace. Running python skills/patent-map/tools/ensure_model.py first is a good idea.
First use requires no manual vault setup: the initial ingest initializes everything automatically, CSS, Bases, indexes, and graph colors included. Your part is limited to installing Obsidian and configuring the vault path, plus optionally installing Dataview or similar from the community plugin market. Steps and the plugin checklist are in the repo’s obsidian-setup-guide.md, and after delivery the agent follows obsidian_plugin_guide.md to walk through optional plugins.
Two everyday entry points:
python skills/patent-reader/tools/extract/fetch_patent_pdf.py --pub CN… -o outputs/patent_reader/RUN
python skills/patent-reader/tools/vault/write_patent_obsidian_note.py --help
The toolchain layers into shared/, extract/, analyze/, and vault/, documented in the tools README.
What the library looks like once it fills up:



A single note, read once and forgotten, is barely an asset. The linked term network and relationship graph are what you come back to, and the more patents you read, the wider that gap grows.
Practical checklist
-
Clone the full repository into .claude/skills/or~/.cursor/skills/patent-disclosure-skill/, keeping the folder namepatent-disclosure-skill, with everyskills/patent-*subpackage included. -
Install Python 3.9+, then run pip install -r requirements.txtfrom the skill root. -
Run browser.py --probe. Anok=trueunlocks image rendering and CNIPA search; with neither Chrome nor Edge present, runplaywright install chromiumonce. -
Install requirements-pdf.txtonly when the scan directory contains PDFs; install matplotlib only after theomml_text_fallbackprompt and your confirmation. -
A disclosure defaults to invention unless you say otherwise; run the four lineart commands before utility model or design finalization unless PATENT_SKILL_SKIP_LINEART=1. -
With .stepfiles present, let the disclosure land first, then confirm before CadQuery installs (isolated venv, Python 3.10–3.12). -
Treat complete: trueas the only “finished” signal for searches; exit code 3 means partial results, never claim “all”, and do not default to--complete. -
On Windows, trust exit codes and machine-readable prefixes; avoid 2>&1; setPYTHONUTF8=1if output looks garbled. -
Name application files, docket, patent map, office-action support, and policy briefs explicitly; application files also need a disclosure directory, and a gate exit code of 2 means go back and complete the disclosure. -
Install Obsidian if you want graphs and indexes; first ingest auto-initializes the vault, and vector models belong in the documents directory, not the workspace.
Quick reference
FAQ
Do I need Python if I only hand-write Markdown?
No. Python is required only for running the repository’s scripts.
Does a default disclosure need matplotlib?
No. Install it only when finalization prints omml_text_fallback on stderr and you confirm, then rerun the Word conversion with --math-render.
Is Chinese text on Windows stderr a failure?
No. Judge by the exit code and machine-readable prefixes. A NativeCommandError does not indicate failure, and chcp 65001 is unnecessary.
What does search exit code 3 mean?
Partial results. Only complete: true means the last page was reached, and partial results must never be presented as the full set.
Can I skip lineart for a utility model?
Not by default. Set PATENT_SKILL_SKIP_LINEART=1 or state explicitly that you do not want line drawings.
Why did the agent ignore my “write the application” request?
Application files are a named trigger and require a disclosure directory. Missing schema, lineart, or the disclosure stops the run and points you back to complete the disclosure first.
Can CadQuery go into the main Python environment?
No. It installs only into an isolated venv running Python 3.10 through 3.12, independent of the main dependencies.
What happens without Obsidian?
Everything still works, with interpretations landing in outputs/patent_reader/. What you give up is the graph, the index, and the term network, which weakens the long-term payoff.

