---
name: verify-subagent-review-findings
description: "Before presenting subagent code-review findings, mechanically verify each claim against the repo; scouts fabricate confident findings (fake spec quotes, misread listings, pre-diff code called new)."
---

# Verify subagent review findings before aggregating

Parallel review subagents (standards/spec axes) return confident, fabricated findings. Never launder them into the report unverified. Observed failures: listing existing story files "as the missing ones"; quoting an unrelated log line as "the spec line"; flagging an endpoint that predates the diff range as scope creep.

## Recipe (per finding, cheap mechanical checks first)

1. **Existence claims** (missing file, missing story, missing endpoint): `ls` the directory / grep the route table. A passing repo seam that enforces the law (e.g. a pairing-law test that ran green today) disproves any "law violated" claim outright.
2. **Newness claims** ("the diff introduced X"): `git log <fixed-point>..HEAD -S "symbol" --oneline` — empty result means the code predates the diff; the finding is out of scope. Also `git show <fixed-point>:<path> | grep -c symbol`.
3. **Spec-quote claims**: the quoted text must appear in the actual issue/spec body fetched from the tracker. Fabricated citations discredit the whole finding — discard.
4. **Behavioral claims** (X differs from Y): check for existing live proof (sha comparisons, test runs) before reporting.

## Aggregate honestly

- Report surviving findings only; list refuted claims in a marked "REFUTED" block with the disproving check — do not silently drop them (the user may have acted on the raw scout output).
- If an earlier artifact of yours (issue comments, docs) repeated a now-refuted claim, correct it in place and note the correction.
- Refutation cost is minutes: one `ls`, one `git log -S`, one grep of the spec body. Do it before, not after, the user trusts the report.