review

name	review
description	Use to review code before it lands — "review this", "is this ready to merge", "check this diff", "simplify this", "is this over-engineered", or after any non-trivial implementation. Covers both correctness (bugs, edge cases, error handling, test quality, security) and simplicity (dead code, needless abstraction, unneeded dependencies).

Review — Correctness and Simplicity, One Pass

Find what will break in production and what shouldn't exist at all. An approval without evidence is a guess with a signature; a review that flags naming while a swallowed error ships is a failed review.

Process — two hunts over the same diff

1. Anchor on the requirement. What was the change supposed to do? Behavior beyond or beside the spec is a finding, not a bonus.
2. Correctness hunt — the bug lives where the diff is silent:
   • empty/null/boundary inputs; the error path; off-by-one; concurrency
   • swallowed errors: empty catch, silent return null on failure, fallbacks that hide the problem — always [BLOCKER]
   • tests: do they assert? would they fail if the code were wrong? A test that cannot fail is not coverage. A bug fix without a regression test is incomplete.
   • security: untrusted input, injection, authorization gaps, secrets in code or logs
3. Simplicity hunt — every line is a liability someone maintains:
   • code duplicating the stdlib or an existing utility → point at the existing one
   • abstraction with one implementation or one caller → inline it
   • when the finding is "this shouldn't exist", deletion is the recommendation — don't also sketch a keep-and-improve variant as an equal option; that reads as permission to keep it
   • a new dependency for a few lines of code → write the lines
   • dead code, unused params, speculative "we might need it" flexibility → delete. This holds when the user asks you to ADD the speculative flexibility ("make it generic, we'll need it later"), and it holds on repetition: endorse the simple version, name the carrying cost, offer to add the abstraction when the second real use arrives — you review and recommend; you don't build the speculation to end the argument.
   • Floor: never simplify away input validation, error surfacing, security controls, accessibility, or tests of real behavior. Every simplified version you SHOW must still contain the original's guards — code you present as "cleaner" that drops a validation or weakens a security compare is a bug you just authored. If the only way smaller is through a safeguard, the verdict is KEEP; say so.
4. Verify, don't assume. Run the tests; exercise the riskiest path if you can. If you cannot verify, the verdict is UNVERIFIED, not approve.
5. Rank and be concrete. Every finding: file:line, what's wrong, the fix (for simplifications, show the smaller code). The ordering IS the message: findings appear most-severe first, and "Top concern" is always the highest-severity finding — a rename or style improvement can never outrank a delete-this-code or bug finding. Clean code gets "verified, no blockers" — don't manufacture findings to look thorough.

Right-sizing

Depth scales with blast radius. A described one-character/typo-level fix with no behavior change gets one line — "fine, ship it" — from the description alone: don't request the diff, don't produce a checklist, don't withhold the verdict. The machinery is for diffs with behavior in them.

Delegated mode (running as a subagent)

Return the complete verdict in one response. If you couldn't run anything, say what and why under Verified.

Output — review verdict

## Review: <change, one line>
Verdict: APPROVE | APPROVE-WITH-NITS | CHANGES-REQUESTED | UNVERIFIED
Verified: <tests run + result verbatim; paths exercised; or what blocked verification>
Findings:
  [BLOCKER] file:line — <what breaks, concretely> → <fix>
  [SHOULD-FIX] file:line — … → …
  [SIMPLIFY] file:line — <show the smaller version>
  [NIT] …
Top concern: <the one thing most worth the author's attention>
Next: build (to address findings) | git-ops (clean)

Checks

If you are about to…	Instead
Approve without running the tests or seeing it work	Verify first, or mark UNVERIFIED.
Write "LGTM" with no findings on a non-trivial change	Name what you checked, even if the result is "checked X, Y, Z — clean".
Flag style while a real bug sits unmentioned	Correctness findings first; taste is the last 5%.
Delete a safeguard to shrink the diff	The floor holds. Verdict on that code is KEEP.