| name | rescan |
| description | Re-run an existing prior-art scan against today's ecosystem and append a dated revision, without rewriting the original. Use when the user says "is that still true", "re-check that scan", "has anything appeared since", "refresh the prior art on X", or is about to act on a scan that is months old. Also used to sweep every stale `build` verdict at once. |
rescan
A prior-art scan is a claim about a date. This re-tests one against today and records the
difference.
Revisions append. Nothing above the Revisions heading is ever rewritten. The value of
an old scan is partly the record of what was true then — "nothing existed in August,
something did by January" tells you the space is filling up, which neither snapshot says
on its own. Overwrite it and you have a mediocre new scan instead of a trend.
Inputs
- target (required): a scan slug, a filename, or
--stale to sweep everything past
its shelf life.
Procedure
1. Pick the targets
Named target: read the file, take the original spec verbatim. Do not re-derive the
acceptance criteria — the whole point is testing the same spec against a new date. If
the requirement itself has genuinely changed, that is a new scan with a new slug, and the
old one gets a revision noting the supersession.
--stale, using the shelf lives in docs/verdicts.md:
| Priority | What |
|---|
| 1 | build verdicts older than ~6 months where nothing was built |
| 2 | contribute verdicts of any age — the PR either landed or died |
| 3 | adopt / fork verdicts whose dependency has gone quiet |
Skip already-have-it and native unless asked; they don't decay.
Report the list before working it, and cap a sweep at what can be done properly. Six
shallow re-scans are worth less than two real ones.
2. Re-run the surfaces
Work docs/method.md again. Two shortcuts that are legitimate and one that isn't:
- Legitimate: date-bound the queries where the surface supports it — the MCP registry
takes
updated_since; gh search repos can filter on pushed:>YYYY-MM-DD.
- Legitimate: re-check named candidates from the original directly before searching
broadly. A candidate that has since died changes the verdict on its own.
- Not legitimate: skipping a surface because it was empty last time. Empty surfaces
are exactly where new things appear.
Re-check the original candidates for liveness in both directions. A fork verdict
reverts to contribute if the upstream came back to life.
3. Decide what changed
Three outcomes, all worth writing:
| Outcome | Record |
|---|
| Verdict holds | Say so, with today's date and what you re-ran. This is the common case and it is not a wasted revision — it extends the claim's validity |
| Verdict changes | New verdict, what appeared or died, and what the user should now do |
| Spec has drifted | The requirement is no longer the one that was written down. Note it, open a new scan, mark this one superseded |
4. Write the revision
Append under ## Revisions:
### 2026-11-03 — adopt (was: build)
`someone/some-plugin` appeared 2026-09; first release 2026-10-14, meets criteria 1–3,
misses NICE 4. Re-ran: substrate, GitHub topic + code search, MCP registry, web.
The original `build` verdict is superseded — nothing was built in the interim, so
nothing to migrate.
**Install:** `/plugin install some-plugin@someone`
Then update the frontmatter: verdict: to the current one, and append today's date to
revised: []. Leave date: at the original — it is when the question was first asked.
Finally run reindex, since the table reads verdict:.
Guardrails
- Never edit above
## Revisions.
- Never re-derive the criteria for a rescan.
- A revision that says "still nothing" is a real deliverable. Write it.
- If a surface is unavailable today, say which, and drop
confidence accordingly rather
than quietly claiming the same coverage as last time.
