patent-application-creator
End-to-end patent campaign from ANY raw material ("here is some information; make a patent") to a filing-ready provisional package - invention mining, worth-it economics (design-around cost, detectability), exhaustive adversarial prior art, claims-first drafting, machine-verified compliance, hostile
By robthepcguy · 787 installs
npx skills add robthepcguy/claude-patent-creator --skill patent-application-creator
Source repository · Upstream listing
Patent Application Creator Skill
Run a complete patent campaign: take whatever the user has — a codebase, an
invention disclosure, scattered notes — and either produce a filing ready
provisional package or a reasoned, evidence backed explanation of why not.
This workflow was hardened by running it for real (a full campaign over a
production codebase, July 2026). Every phase below exists because skipping
it cost something in that campaign.
The contract
The honest outcome is the deliverable. "Nothing here clears the
novelty bar, and here is the prior art that kills each candidate" is a
SUCCESS, not a failure. So is "this is patentable but not worth your
money — file nothing, or publish defensively." Never inflate a weak
candidate.
The campaign guards the user's money, not just their filing. The
population this tool serves cannot afford a technically perfect package
for a commercially worthless patent. The worth it question is asked
BEFORE the expensive phases and re asked every time the claims narrow —
a campaign that only discovers "small fence" at the end has already
spent the user's budget answering the wrong question.
Machine checks gate, humans verify. Every automated finding marked
LOW confidence gets manual verification; every clean bill of health names
the checks that ran AND the checks that were skipped.
Dates matter. Prior art is being published continuously; note recency
threats found during the sweep and say so in the package. Filing sooner
beats polishing longer for a provisional.
The AI is never the inventor. The user is. The AI mines, searches,
drafts, and verifies; the user's creation is what gets protected.
Phase 0 — Intake (any raw material)
Accept the rough ask as is. If the material is a codebase, do NOT ask for a
disclosure — mining is Phase 1's job. Ask only what cannot be derived:
inventor name(s), and whether any of it has been publicly disclosed or sold
(statutory bar dates). Then AUDIT the inventor's own public footprint —
released products, demos, public repositories, marketing pages — and record
first disclosure dates: the inventor's own disclosures start the US
grace period clock and can immediately forfeit foreign rights. Do this
before drafting, not after.
Phase 1 — Invention mining
Hunt CONCRETE TECHNICAL MECHANISMS, not features. For a codebase, fan out
readers (one per subsystem) with this lens: a candidate must be (a) specific
and implemented, (b) solving a technical problem, (c) arguably
unconventional — never textbook auth/CRUD/caching. For each candidate
capture: mechanism (how, not what), evidence location, problem solved,
conventional alternative beaten, why the difference is non obvious.
Then triage (kill/pursue) with these screens:
Section 101 screen : billing, commerce, and organizing human activity
subject matter draws Alice rejections regardless of cleverness —
deprioritize.
Crowded field screen : thread pools, retries, distributed sync,
testing methods — demand an unusual twist or kill.
Unification screen : look for ONE principle several candidates
instantiate; a system claim with multiple embodiments beats scattered
small claims.
Phase 1 H — History mining (when the material is a git repository)
The current code shows WHAT exists; history shows what it BEAT, how hard
it was, and when — and it holds mechanisms that no reader of HEAD can ever
find, because they died in abandoned branches. For an inventor who rebuilds
often, the abandoned branches are where the cleanest ground lives: a
mechanism that never merged never deployed, so it has no disclosure clock
running and full foreign rights intact. Run this pass alongside the
Phase 1 code mining whenever the raw material has git history.
The funnel (validated on a real 808 commit, 9 branch + 92 PR ref repo:
~2.5M agent tokens, minutes of wall clock):
1. Enumerate everything. Mirror clone; fetch +refs/pull/ /head too.
git rev list all is the universe. State the limit honestly: a host
only serves commits still reachable from refs — force pushed away
history is gone, so the stamp says "what the host still has," never
"all that ever existed."
2. Collapse by patch id. git rev list all git diff tree stdin
p r git patch id stable — cherry picks and rebases across
hundreds of branches collapse to one entry each. Cost scales with
unique patches, not branches. (Do NOT pass no commit id ; patch id
needs the commit lines to attribute patches.)
3. Mechanical triage into NAMED buckets. Exclude noise subjects
(deps/docs/merges), lockfile/binary only patches, and tiny diffs —
every exclusion lands in a bucket with its subject recorded. Coverage
must stay arithmetic: universe = read + excluded, reconcilable.
4. Read EVERY survivor. Batch patches (~30/agent, diffs capped
~7KB with the cap disclosed) and require each reader to return one
verdict per patch AND the count of patches it saw — reconcile counts
per batch. MECHANISM vs ROUTINE, with "what conventional approach the
diff replaces" captured. Instruct readers explicitly: NEVER downgrade
abandoned or unfinished work — abandoned cleverness is the target.
5. Cluster and locate. Same mechanism across many commits is one
cluster. For each needle: git branch contains and reachability
against the default branch, then verify against the SHIPPED code
whether the mechanism migrated (a bridge branch can make "stranded"
commits' content live elsewhere — check the deployed source, not the
branch topology). Only "absent from everything shipped" earns the
no disclosure clock label.
6. Second adversarial pass until dry. One lens misses; re read the
ROUTINE pile with a "what did pass 1 misjudge?" prompt until a pass
finds nothing new.
History also supplies what HEAD cannot: the diff shows the conventional
alternative being replaced (Phase 1's hardest field to fill), a string of
failed attempts before the breakthrough is objective non obviousness
evidence, and commit dates + authorship are conception records. Feed the
surviving needles into the Phase 1 triage screens (including worth it)
like any other candidate.
Phase 2 — Prior art: every outlet, adversarially
Patents alone are NOT sufficient for software: the killing art usually
lives in products, open source, standards, and papers. Sweep ALL of:
1. Patents : search patents bigquery (keyword search is term AND, so
3 4 terms max), search patents by cpc bigquery (identify the CPC
classes first), Google Patents pages for deep reads (free). Cost
awareness: a default keyword search scans roughly 325 GiB (about $2
billed, or a third of a sandbox project's free month).
2. Non patent literature : fan out adversarial web research agents per
claim cluster, each instructed to KILL the claim: products (what do the
incumbent writing/coding assistants actually do?), open source (read
the code), standards bodies, arXiv, engineering blogs.
3. Instruct every agent to return per item verdicts: "what ours has that
this lacks" or "ANTICIPATES". Aggregate into: CLEAN GROUND (recite in
independent claims), KILL ZONES (never claim alone), MANDATORY CLAIM
READS (references an attorney must read before the utility filing),
and UNRESOLVED LEADS (bot blocked pages and the like — escalate to the
user, never silently drop).
Language discipline (non negotiable). Sweep results support only
statements of the form "no anticipation found in [outlets searched] as of
[date]" backed by a dated element by element chart. Never write "nobody",
"no art exists", "swept clean", or "survives" as facts — an agent's read of
a repository is a snapshot of an evolving codebase, and a second read weeks
later can contradict it. And a date rule that is easy to get wrong under
urgency: published third party art can never be outrun. Anything
already public is prior art against any later filing, grace period or not;
filing urgency arguments apply only to disclosures that have not happened
yet.
Decision gate: if no candidate has clean ground, write the no go report
(candidates, killing references, per candidate reasoning) and STOP. That
report is the deliverable. Then re run the worth it screen on each
survivor AT ITS POST SWEEP WIDTH: the clean ground is always narrower
than the Phase 1 candidate, and the question is whether the SMALLER
fence still costs a competitor anything. A survivor that is now avoidable
by an obvious variant goes in the no go report too — with its design around
named, and with the defensive publication alternative stated (near free,
permanent, kills later third party patents on the same mechanism).
Phase 3 — Claims first drafting
Draft claims BEFORE the specification; the clean ground dictates them.
Each independent claim's load bearing limitation must be an element the
sweep found nowhere. Elements found in isolation go in dependents.
Proper form: "The method of claim N, wherein ..." — never shorthand
(the analyzer's dependency tracking and the examiner both need it).
Consistent terms: introduce with "a/an", reference with "the" using the
IDENTICAL noun phrase.
Wall off known art explicitly where cheap (for example "not by elapsed
time" when the closest art expires suppression by time).
Track the shrinking yard. Every wall off and every narrowing
amendment (here and again after the Phase 5 attack pass) makes the
claim easier to design around. After the attack pass settles the final
claim shape, re run the worth it screen one last time on what actually
survived; record the verdict (design around cost, detectability,
provisional vs defensive publication recommendation) in the package
README so the user decides about the patent they can GET, not the one
they imagined.
Then the specification: field, background (the problems, framed
technically), summary (one paragraph per independent claim), brief
description of drawings, detailed description covering EVERY embodiment
with reference numerals, reduction to practice, and a variations paragraph
(broaden: any model, any similarity metric, thresholds exemplary). The spec
must contain each claim term VERBATIM — the support checker verifies this.
Source verified claims (mandatory). Every limitation of every claim
must be verified against the IMPLEMENTATION itself — open the code — not
against a mining agent's summary and not against header comments, which go
stale (a real campaign found a contract doc describing closest match
relocation while the executable body below it contained an ambiguity
refusal gate; the claim drafted from the summary was wrong in a way that
contradicted the specification). The reduction to practice is the tiebreak
for what claims, spec, and figures must all say — and they must all say
the SAME algorithm, or each variant must be expressly a separate
embodiment. Never claim behavior the implementation does not have (a
"valid result of a preservation type plan" reclassification that the code
never performs is new matter waiting to be rejected).
Terminal state completeness. Any specification asserting deterministic
termination, bounded retries, or guaranteed outcomes must enumerate EVERY
terminal state and every budget transition — including the unglamorous
ones (mechanical exhaustion, global overrun backstops) — and the figure
must show every branch with labeled edges.
Figures: create block diagram for the system (numbered components
matching the spec), render diagram with hand written DOT per independent
claim so decision branches carry Yes/No edge labels ( create flowchart
does not label edges), with reference numerals on every node.
Phase 4 — Machine verification loop (iterate to clean)
1. patent creator config set PATENT ENABLE ANTECEDENT CHECK 1 — the
antecedent check is opt in; a campaign MUST run it.
2. review patent claims on the full claim set. Fix genuine fi