Fresh-Context Review Prompt
This is where the bugs die.
Five real catches from 8BEETY's review passes: a codec level that corrupted exported videos, two octaves silently dropped on the SNES, a double-gain bug that clipped all 16-bit audio, WAV exports that lost a hard-panned channel entirely, an FM release envelope that could never sound. Every one of those was caught by a review or a test before a user ever hit it. Not one of them announced itself. The build was green and the feature demoed fine. The output was quietly wrong in a way you would have shipped.
The context that wrote the code cannot find these. It knows what it meant, so it reads its own diff and sees its intention rather than its output. A reviewer that did not write the code has no intention to protect. Give it the spec section, the diff, and an instruction to verify claims by running things rather than by reading them, and it will go and check. The instruction to run is the part people leave out, and it is the part that turns a review from an opinion into a result.
# Review: [feature or task name]
You did not write this code. Do not assume it works. Your job is not to be
agreeable, and it is not to find something either. If nothing is wrong, say
so and show the commands you ran to get there.
## What to read
1. `SPEC.md` §[N], [section title]. The spec is the standard. Code that
disagrees with it is wrong even if it is well written.
2. The diff: `git diff [base]..[head]`, files changed listed below.
3. The implementation summary in the next section, which is a set of claims,
not a set of facts.
## Claims to check
[Paste what the implementer said it did, one claim per line. If they wrote a
paragraph, break it into claims yourself before you start.]
- Claim 1: [...]
- Claim 2: [...]
## How to verify
For each claim above, verify it by running something. Not by reading the
code and agreeing with it. Running.
- Quote the exact command you ran and its real output. Truncate long output,
do not paraphrase it.
- End every claim with exactly one of: VERIFIED, COULD NOT VERIFY, FALSE.
- "Looks correct" is not a verdict. If the claim is not checkable by running
anything, say COULD NOT VERIFY and say what would make it checkable.
## Look specifically for
- **Data that gets dropped silently.** Entries filtered out of a list,
channels or fields lost in a mapping, values clamped or rounded with no
log, a branch that returns early on a case that really happens. Count what
goes in and count what comes out.
- **Off-by-one at boundaries.** First element, last element, empty input,
single-element input, the maximum the spec names, and one past it.
- **Error paths that cannot happen.** A catch that swallows, a default that
hides a missing case, a fallback that turns a bug into a plausible-looking
feature. Force each one to run and see what the user would get.
- **Numbers that do not match the spec.** Check every constant in the diff
against `SPEC.md` §[N], one at a time. Not "the math looks right".
- **Tests that pass without testing.** Assertions against a mock, snapshots
regenerated to match the new output, a test that would still pass if the
implementation were deleted. Try deleting it and see.
## Report format
Per claim:
- Verdict: VERIFIED / COULD NOT VERIFY / FALSE
- Command run:
- Output:
- If not verified: what you would need in order to verify it.
Then a defect list, worst first. Each defect gets the file, what is wrong,
what the spec says instead, and why it matters to a user.
Do not summarize the feature back to me. I know what it is supposed to do.
Tell me what it does.Adaptation notes:
- The reviewer has to be a separate context. Asking the session that just wrote the code to review the code produces a confident summary of what it meant to write. This is the whole mechanism, and running the review in the same session throws it away while keeping the paperwork.
- When the reviewer and the implementer disagree, the spec breaks the tie. If the spec is silent, that is the real finding: you have located a decision nobody made. Make it, write it into the spec, then let them both re-read.
- Run a whole-feature review at the end of a milestone, not only per task. Per-task reviews catch defects inside a diff. The end-of-milestone pass catches the ones that live between diffs, where two correct tasks add up to something wrong.
- Paste the implementation summary in as claims, in the implementer's own words. Rewriting it into what you think it meant is how you accidentally review your own understanding instead of their work.
- If every review comes back clean, the prompt is being read as a formality. Check that the reviewer is actually running commands by looking for the quoted output, and if there is none, the review did not happen.