prior-art-scan

name

prior-art-scan

description

Determine whether a Claude Code plugin, MCP server, skill or native feature already exists for a stated requirement, and return a build-vs-adopt verdict with a dated report. Use when the user asks "is there a plugin for X", "does an MCP exist for Y", "has anyone built this", "do I need to build this myself", "check prior art before I build", "is this blue sky", or describes a capability they want and wonders whether to build it. Writes scans/<date>-<slug>.md and updates the index.

prior-art-scan

Answer one question — does this already exist — well enough that the answer is worth keeping.

The verdict matters less than the evidence behind it. A "no" that lists six surfaces searched on a named date is useful for a year. A "no" from one web search is worth nothing and, worse, licenses building something redundant.

Inputs

• requirement (required): what the user wants to be able to do. Usually one sentence.
• shape (optional): plugin / MCP server / skill / hook / CLI. If unstated, don't assume — step 1 works it out, and assuming narrows the search prematurely.
• depth (optional): quick (steps 1–2 and 4 only, for an obvious question) or the default full sweep. A quick scan may not conclude build; see Guardrails.

Procedure

1. Write the spec before you search

Non-negotiable, and the step most likely to be skipped. Search first and you will grade whatever you find on a curve, because by then you want the search to be over.

Produce, from the requirement:

• One sentence stating the capability, in the user's terms.
• 3–6 acceptance criteria, each marked MUST or NICE. A MUST is something whose absence means the candidate does not count — not something you'd prefer.
• Out of scope — one or two lines on what this is not, to keep the search honest when a near-miss shows up.
• Plausible shapes — could this be a plugin, an MCP server, a skill, a hook, an existing CLI, or a feature Claude Code already ships? List every shape that could satisfy the criteria. Each one is a different search surface, and the most common scan failure is searching only for the shape the user happened to name.

Show the spec before proceeding. If the requirement is one ambiguous line and the criteria could go two materially different ways, ask — once. Otherwise draft the criteria yourself and say you've drafted them.

2. Check what the user already has

Cheapest surface, highest hit rate, and the most embarrassing one to skip. Run all four:

Surface	How
Skills substrate	viking__find on viking://user/daniel/skills, 2–3 differently-worded queries
Own repos	gh repo list danielrosehill --limit 1000 --json name,description,visibility,updatedAt then filter
Marketplaces	the public and private marketplace manifests — .claude-plugin/marketplace.json
Live MCP servers	already-registered gateway upstreams; the capability may be one tool call away

gh repo list truncates silently without an explicit --limit. A suspiciously round result count means you got a capped page, not the whole list.

A hit here ends the scan at already-have-it — but still write the report, because "I already built this" is exactly the finding that fails to stick otherwise. Name the thing and how to invoke it.

3. Check first-party before community

Claude Code and the API absorb capability quickly, and last year's plugin is regularly this year's built-in. Before searching the community ecosystem, check whether the requirement is now native: agent skills, hooks, subagents, plugins, sandboxing, MCP support, and the API's own tooling. docs.claude.com/en/docs/claude-code, the anthropics/skills repo, and the release notes.

If it's native, that's verdict native, and it is the best possible outcome — nothing to install, nothing to maintain.

4. Search the Claude extension ecosystem

Full queries and their blind spots are in docs/method.md; the short form:

gh search repos --topic claude-code-plugin --limit 50 --json fullName,description,stargazersCount,updatedAt
gh search repos "<keywords> claude code plugin" --limit 30 --json fullName,description,updatedAt
gh search code --filename marketplace.json '<keyword>' --limit 20 --json repository,path
gh search code --filename SKILL.md '<keyword>' --limit 20 --json repository,path

Code search only indexes public default branches, is heavily rate-limited, and misses a great deal. Treat a null result from gh search code as weak evidence and say so in the report.

5. Search the MCP ecosystem

The requirement is frequently better served by an MCP server than a plugin, so search this surface even when the user asked about plugins.

curl -s "https://registry.modelcontextprotocol.io/v0/servers?search=<term>&limit=20" | jq '.servers[].server | {name, description, repository}'

Then GitHub topic:mcp-server combined with keywords — the topic alone returns tens of thousands of repos and is useless unfiltered — and the directories listed in docs/method.md.

Ask separately whether the underlying service ships an official MCP server. That is the strongest signal available: it means the capability exists, is vendor-maintained, and needs wiring rather than building.

6. Sweep the long tail

WebSearch first. Escalate to exa__web_search_exa when route 1 comes back thin — describe the ideal page rather than typing keywords. Awesome-lists (awesome-claude-code, awesome-mcp-servers) are worth one look each and are always somewhat stale.

7. Grade candidates against the spec, not against each other

For every candidate that plausibly qualifies, record:

Field	Why
What it actually is	plugin / MCP / skill / CLI — often not what the listing implies
Where	repo URL, install line
Alive?	last commit, last release, whether issues get answered
MUSTs met	per criterion, met / partial / not
The catch	the specific reason it does or doesn't qualify

Two rules that decide most scans:

• Liveness is a criterion, not a footnote. An exact match abandoned eighteen months ago is usually worse than nothing: it will look like the answer to the next person, and it will not survive the next Claude Code change.
• Stars are not fitness. A 90k-star repo that misses a MUST is a miss. Popularity measures a project's audience, not its match to this spec.

8. Call it

Pick one verdict from docs/verdicts.md and name the criterion that decided it. If the verdict rests on a MUST that the user might soften, say so explicitly — "this becomes adopt if the geo-specific delivery check is downgraded to NICE" is far more useful than a flat build.

9. Write the report

scans/YYYY-MM-DD-<slug>.md, from scans/_TEMPLATE.md. Frontmatter is machine-read by reindex, so keep the field names exactly as templated.

The section that earns this repo its keep is Where I looked — every surface, the actual query, and the result including the empty ones. A query that returned nothing is a finding: it tells the next agent not to spend that minute again.

Write it for someone who wasn't here. Name versions and dates. Mark anything inferred as inferred.

10. Index and hand off

Add the row to scans/README.md (or run reindex), then close with the next action:

Verdict	Hand off to
already-have-it	the thing itself — name it and how to invoke it
native	the doc page for the feature
adopt / adopt-with-gaps	the install command, verbatim
contribute	the upstream repo and the issue to open
fork	the repo to fork, plus what would have to change
wrong-shape	whatever the right shape is
build	claude-rudder:what-thing-pick to choose the primitive, then create-claude-plugins:new-claude-plugin

Guardrails

• Never conclude build from fewer than four surfaces. Minimum: the user's own inventory, first-party, GitHub, and either the MCP registry or a web sweep. A quick scan can return already-have-it, adopt or native; it cannot return build, because a negative needs the coverage.
• State coverage, not just conclusion. "Nothing found" and "nothing exists" are different claims. The report makes the first; only the verdict field makes the second, and it carries a confidence level.
• Do not soften the spec to make a candidate fit. If you find yourself rereading a MUST charitably, the answer is adopt-with-gaps with the gap named, not adopt.
• Do not open a scan for a requirement the user did not state. Speculative scans clutter the index and decay unread.
• Record dead ends. Deleting the failed queries removes most of the report's value.
• One scan per file. Two requirements that seem related are two scans; they will decay at different rates and get revisited separately.