verify¶
Read-only verification and prospective impact analysis
A disciplined way to check AI answers, plans, PR descriptions, migration
notes, and docs against the actual repository before relying on them — with
per-claim verdicts backed by file:line evidence — and to map the blast
radius of a proposed change before implementation.
verify declares dependencies: ["retrieval-core"], so it composes with the
retrieval spine to find evidence efficiently.
Install¶
Components¶
| Component | What it is |
|---|---|
verifier subagent |
A read-only verifier with only Read, Grep, and Glob. Checks a claim set against the repository and returns per-claim verdicts with file:line evidence. |
verify-before-trust skill |
A main-agent discipline for decomposing claims, locating primary evidence, assigning verdicts, and deciding when to delegate to the verifier. |
change-impact skill |
Prospective blast-radius analysis across direct dependents, runtime/config/data/schema surfaces, tests, docs/operations, compatibility, and unknowns. |
/analyze-impact command |
Applies the change-impact report contract to a proposal, diff, commit, PR, or design decision. |
Read-only by design¶
Safe as an independent second read
The verifier cannot edit files, write files, or run shell commands. It can confirm, question, or refute claims without mutating the tree or grading its own changes.
Each claim gets one of four verdicts, with evidence:
| Verdict | Meaning |
|---|---|
| confirmed | Primary evidence supports the claim (path:line cited). |
| dubious | Evidence is partial, ambiguous, or indirect. |
| refuted | Primary evidence contradicts the claim. |
| unable-to-check | Read-only inspection cannot settle it. States what would. |
verify owns the evidence slot as well as the taxonomy, and defines exactly
three forms so dependents inherit them rather than inventing their own:
| Form | When | Example |
|---|---|---|
| Repository | any verdict settled by static inspection | evidence (src/a.ts:12) |
| Observation | a claim reassessed from a caller-supplied runtime-evidence report that retained a durable artifact, including an inconclusive one |
evidence (command-id=api-health; report=…/run-4213.json) |
| None | dubious or unable-to-check with nothing citable — no report, or a report that retained no artifact |
evidence (none) |
The observation source is command-id=<allowlist key> for the sanctioned
runner, or tool=<approved tool>@<target> for an approved optional-tool
observation where no reviewed command can represent the claim. An artifact
pointer is required either way: an observation nobody else can inspect is not
citable, so a no-artifact attempt uses evidence (none) and names the attempted
source and the missing artifact in the note.
One verdict cites one form. On reassessment the observation citation replaces the evidence slot rather than joining it, and any static context moves to the note.
Escalating an unresolved runtime claim¶
unable-to-check is a route, not a dead end
A runtime claim that static evidence cannot settle must name the observation
that would settle it. When runtime-evidence is
installed, that observation can be escalated with
/collect-runtime-evidence, which runs a pre-reviewed allowlist command ID
— or an approved browser/debugger observation when no command fits. The
report comes back here, and the same claim is reassessed under this
taxonomy — verification keeps ownership of the verdict.
The escalation is optional. verify does not depend on runtime-evidence;
the dependency runs the other way. Without it, unable-to-check plus the
named missing capability is the correct final answer.
Change-impact is prospective and intended to be non-mutating. For history,
structured-data, and git grep structural search it ships an enforced executor,
scripts/run-impact-inspection.py: a stdlib, no-shell runner with a fixed,
plugin-owned catalog of read-only operations. The runner builds each argv
itself, validates and positionally substitutes parameters, confines paths to the
analysis root, and scrubs the environment, so the named write and exec vectors
(git's --output write flag, git grep's --open-files-in-pager exec flag,
yq's in-place flag) cannot land. A prefix-matched command allowlist could not
express any of that. For code-intelligence — and YAML when yq is absent — no
enforced operation exists, so the skill declares a surface of file reading plus
search and reaches those modalities only by delegating, disclosing that as an
unenforced choice.
allowed-tools is not an enforcement control
Omitting command grants avoids pre-approving them; it does not deny them,
and it is not portable across hosts. As the boundary map
states, host permissions and operator review govern what a delegate actually
executes. Where an enforced guarantee is needed for history, structured-data,
or git grep, it comes from the inspection runner; the runner never silently
downgrades, reporting a missing tool as unavailable so the modality is
marked unreached rather than quietly delegated.
It separates observed repository coupling from inferred future risk and unknowns:
For broad repositories, plan-execute can optionally parallelize read-only
coverage. It is not a dependency and does not permit implementation work.
Composing with retrieval-core¶
When it isn't obvious how to find evidence, use the retrieval-strategy decision
flow: scope the corpus first, search cheaply, read primary files directly, then
cite exact path:line support.
At a glance¶
| Category | verification |
| Provides | verifier subagent + 2 skills + /analyze-impact |
| Dependencies | retrieval-core |
| License | MIT |