Code Review
Goal: catch what matters, skip what doesn't, and never say "looks good"
about code you haven't actually read.
This is for reviewing OTHER work (a PR, a branch, another agent's output).
For checking your own work, use verify-work.
Steps
Understand the intent first.
What is this change supposed to do? Read the description/ticket/journal
before the diff. A review without intent is just style-nitpicking.
Read in risk order, not file order.
First: anything touching auth, money, data deletion, migrations, public
APIs, concurrency. Then core logic. Then tests. Style last, if at all.
Say which high-risk areas the diff touches — that's the review's spine.
Hunt for the three killers:
- Unintended behavior change — does anything behave differently that
the description doesn't mention?
- Weakened safety — tests loosened/deleted, error handling removed,
validation relaxed, exceptions swallowed?
- Hidden scope — changes that have nothing to do with the stated
intent, riding along unreviewed?
Back every finding with evidence.
Point to the line, state the failure scenario ("if two requests hit this
concurrently, X"). A finding you cannot ground in the code is a question,
not a finding — ask it as one.
Triage, don't flood.
Label each finding: blocker (breaks something / unsafe) /
should-fix (real but not fatal) / nit (take or leave). Report the
2-5 highest-impact spots first. Dozens of nits bury the one blocker —
optimize for signal, not for looking thorough.
Verify claims when stakes are high.
For a blocker-level suspicion, don't just assert — run the code or write
a quick failing case if the environment allows. Evidence rules apply to
reviews too.
Conclude honestly.
End with one of: approve / approve-with-nits / needs-changes (list the
blockers). "LGTM" on a diff you skimmed is a lie with good manners.
Do not
- Do not review style before correctness.
- Do not demand rewrites to your personal taste — consistency with the
existing codebase wins.
- Do not pass a diff you didn't fully read. If it's too big to review
properly, say that — "split this" is a valid review outcome.
1---2name: code-review3description: Use when reviewing code you did not write in this task — a pull request, a teammate's branch, a diff, or another agent's output. Enforces risk-ordered reading, evidence-backed findings, and severity triage instead of a comment flood.4---56# Code Review78Goal: catch what matters, skip what doesn't, and never say "looks good"9about code you haven't actually read.1011This is for reviewing OTHER work (a PR, a branch, another agent's output).12For checking your own work, use `verify-work`.1314## Steps15161. **Understand the intent first.**17 What is this change supposed to do? Read the description/ticket/journal18 before the diff. A review without intent is just style-nitpicking.19202. **Read in risk order, not file order.**21 First: anything touching auth, money, data deletion, migrations, public22 APIs, concurrency. Then core logic. Then tests. Style last, if at all.23 Say which high-risk areas the diff touches — that's the review's spine.24253. **Hunt for the three killers:**26 - **Unintended behavior change** — does anything behave differently that27 the description doesn't mention?28 - **Weakened safety** — tests loosened/deleted, error handling removed,29 validation relaxed, exceptions swallowed?30 - **Hidden scope** — changes that have nothing to do with the stated31 intent, riding along unreviewed?32334. **Back every finding with evidence.**34 Point to the line, state the failure scenario ("if two requests hit this35 concurrently, X"). A finding you cannot ground in the code is a question,36 not a finding — ask it as one.37385. **Triage, don't flood.**39 Label each finding: **blocker** (breaks something / unsafe) /40 **should-fix** (real but not fatal) / **nit** (take or leave). Report the41 2-5 highest-impact spots first. Dozens of nits bury the one blocker —42 optimize for signal, not for looking thorough.43446. **Verify claims when stakes are high.**45 For a blocker-level suspicion, don't just assert — run the code or write46 a quick failing case if the environment allows. Evidence rules apply to47 reviews too.48497. **Conclude honestly.**50 End with one of: approve / approve-with-nits / needs-changes (list the51 blockers). "LGTM" on a diff you skimmed is a lie with good manners.5253## Do not5455- Do not review style before correctness.56- Do not demand rewrites to your personal taste — consistency with the57 existing codebase wins.58- Do not pass a diff you didn't fully read. If it's too big to review59 properly, say that — "split this" is a valid review outcome.
suleymanbyzt