| 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.
