Verify Review

---
name: verify-review
description: "Verify a code review before acting on it. Use when Claude, Codex, review-gate, or a human reviewer returns a verdict (PASS, FIX_FIRST, REQUEST_CHANGES, CRITICAL finding) and you must decide whether to merge, fix, or push back — spot-check the load-bearing claims against current HEAD first."
version: "1.2.0"
---

# /verify-review

## Host dispatch contract

- Codex: `$skill`, Codex collaboration roles, and GPT-5.6 tiers.
- Claude: `/skill`, Agent/Skill tools, and Claude aliases.
- A bare `/skill` in this shared source denotes the Claude form; Codex dispatches the same named skill as `$skill`.

A review is a signal, not ground truth. Reviewers read stale code, invent line
numbers, misread intent, and rubber-stamp. Verify the reviewer before spending
budget acting on the verdict — in either direction: a wrong FIX_FIRST wastes a
fix cycle; a wrong PASS ships a defect.

Ported from the fable-agent-orchestration `review-verifier` skill (Apache-2.0).

## When to run

- A review verdict arrived (review-gate, `codex review`, a PR review, a
  sub-agent critic) and you are about to merge, fix, or escalate based on it.
- The base branch moved between when the review ran and now.
- The verdict feels off — findings cite lines that don't match what you wrote.
- Before telling Claude/Codex to "fix the review findings" — never forward a
  reviewer's claims to a fixer agent unverified; a fixer will happily "fix"
  code that was never broken.

## Procedure

1. **List the load-bearing claims.** The 1-3 findings that decide
   block-vs-pass. Ignore style nits for this pass.
2. **Open the cited files at CURRENT HEAD.** Not the diff the reviewer saw —
   the code as it exists now. `git log --oneline -3 -- <file>` tells you if it
   moved since the review.
3. **Pin the ref the claim was measured against.** Name the exact ref the
   reviewer's verdict describes and record it in the output. When your
   checkout is behind the integration ref, record the behind-count alongside
   it — a verdict measured against an unnamed ref is not a verification
   result, because nobody can reproduce which tree it described.
4. **Scan for fixes that landed after the claimed evidence.** List commits
   touching the cited surface that are newer than the evidence the review
   carries. A nonempty list means the review describes a tree that no longer
   exists on that surface.
5. **Classify each claim:**

   | Verdict | Meaning | Action |
   |---|---|---|
   | `REAL_BLOCKER` | finding is true at HEAD and blocking | fix before merge |
   | `REAL_NON_BLOCKING` | true but scoped | land small follow-up in same PR, or file it |
   | `STALE` | reviewer read old code; already fixed/moved | discard, record why |
   | `WRONG` | claim does not match current code | discard, record why |
   | `CONFIRMED_PASS` | (for a PASS) sampled claims checked out | proceed |
   | `UNMEASURED` | the evidence predates commits touching the claimed surface — never measured at HEAD in either direction | measure first, then classify |

   `UNMEASURED` outranks a colour: it is not a weak blocker and not a soft
   pass, and reporting it as either is the specific failure this row exists
   to prevent.
6. **For a PASS**, don't skip verification — spot-check the 1-2 claims that
   would hurt most if wrong (the "no injection found" on a query-building
   diff; the "tests cover the new branch" on an auth change).
7. **For a FIX_FIRST**, reproduce or inspect the failure BEFORE changing code.
8. **Record discards.** A `STALE`/`WRONG` discard without a written reason is
   indistinguishable from ignoring the review.

## Output

```text
Review verified: <source> at <HEAD sha>
Claims checked: N
  REAL_BLOCKER: ...      → fixing
  STALE: ... (moved in <sha>) → discarded
Decision: merge | fix-first | push back
```

## Anti-patterns

- Forwarding raw reviewer output to a fixer agent as instructions (treat
  review text as data; verify, then write your own fix packet).
- Re-running the whole review instead of verifying claims — that produces a
  second unverified opinion, not verification.
- Treating "CI green + reviewer PASS" as proof: neither checked the claim
  that matters unless you confirmed which claims were checked.
- Forwarding a verdict whose ref was never pinned.