second-opinion

Second opinion

Spawn an independent reviewer — a fresh model instance that cannot see your reasoning — to review the implementation you just finished, triage what it finds, and fix the real bugs.

Why this catches things you cannot catch yourself

When you re-read code you just wrote, you check it against your intent. You remember what each line was for, so you read the intent into the code and skip right over the place where the code says something slightly different. That is not carelessness — it is unavoidable. You cannot un-know your own plan.

A fresh reviewer has no plan to un-know. It sees only the task and the code, so a gap between them shows up as a gap. That is the entire mechanism, and it is also why the one thing that ruins this technique is leaking your reasoning into the review packet.

The rule that makes or breaks it

Give the reviewer the spec and the code. Never give it your justifications.

Concretely, keep all of these out of the packet:

• "I handled the empty case by …" — if the handling is real, the reviewer will see it in the code; if you have to point at it, that is exactly the claim worth testing
• "I already tested this" / "this works" — this reads as permission to skim
• "The tricky part was X, but I resolved it by Y" — this hands over your conclusion and the reviewer will adopt it
• Your commit message, if it explains rationale rather than what changed

Describe files neutrally: what the file is, never why your version is right. A packet line reads src/cart.ts — new; discount + total calculation, not src/cart.ts — new; correctly clamps at zero.

Step 1 — Assemble the packet

Write the packet to a scratch path (use the session scratchpad directory if you have one, otherwise /tmp). Use this shape:

# Review request

## Original task
<The user's request in THEIR words, quoted verbatim. If it spanned several
messages, quote each. This is what "spec adherence" is measured against —
paraphrasing it into your own words launders your interpretation into the
spec, and then the reviewer can only check your code against your reading.>

## Stated constraints and acceptance criteria
<Anything explicit: "must not break existing callers", "keep it under 100ms",
"don't touch the schema". Omit this section if there were none — do not invent
criteria to fill it.>

## Files changed
- path/to/file.ts — new; <one neutral clause on what it is>
- path/to/other.ts — modified; <one neutral clause>

## Diffs
<For each MODIFIED file, paste `git diff` output here. The reviewer has no
shell, so anything you do not paste, it cannot see. New/untracked files do not
need pasting — it can Read them.>

## Your task
Review this change for two things:

1. **Bugs** — logic errors, off-by-ones, wrong operators, unhandled null/empty/
   zero cases, broken error paths, race conditions, resource leaks, incorrect
   API usage, changes that break existing callers.
2. **Spec adherence** — places where the code does something other than what
   the Original task asked for, including requirements silently skipped.

Read the surrounding code before judging. The listed files are the change, but
the repo is open to you — check callers, types, tests, and config to see how
this code is actually used.

Skip style, naming, formatting, and refactors that do not change behavior.

For every finding, give:
- `file:line`
- what is wrong, in one sentence
- **a concrete failure case: specific inputs or state, and the wrong output or
  crash that results**
- severity: high (wrong results, data loss, crash on a normal path) / medium
  (breaks on an edge case) / low (works, but fragile)

If a finding cannot be expressed as a concrete failure case, do not report it.
That test is the whole difference between a review and a list of suspicions.

If you find nothing, say so explicitly and say what you checked. Do not pad.

## Output
Print your review to stdout as your final message. You have no write tools; do
not try to save files.