| name | code-review |
| description | Review code changes for correctness, error handling, scope creep, and style. Use when the goal mentions reviewing a PR, diff, or file. |
Code Review
Approach a review like a senior engineer who has to live with the consequences of merging this code.
When to use
- The user asks to review, audit, critique, or sanity-check a code change.
- A PR description, diff, or file path is in the task.
- The user wants to know whether a patch is safe to merge.
Procedure
- Read the diff end-to-end before commenting. Skim the full change first — don't react to line 1 before understanding line 200. Form a mental model of what the change is trying to do.
- Match against the stated intent. Does the diff actually accomplish what the PR says? Note unrelated edits as separate items, not approval blockers.
- Walk error and edge paths. Null/undefined, empty arrays, off-by-one, timeout, partial failure, concurrent access. Identify the worst-case input and ask: does the code handle it cleanly?
- Check scope. Refactor mixed with feature work? Stylistic noise? Drive-by renames? Call out scope creep — bug fixes don't need surrounding cleanup.
- Verify tests follow the change. New behavior → new test. Bug fix → regression test that fails without the fix. Test quality matters: a passing assertion that doesn't actually test the change is worse than no test.
- Look for the failing invariant. When something feels wrong, name what specifically would break. "This is wrong" is unhelpful; "this overwrites the cache during concurrent writes" is actionable.
Output
- Group findings by severity: must-fix → should-fix → nit.
- For each finding, cite
file:line and name the failing invariant.
- End with an explicit verdict: ready to merge / needs changes / needs discussion.
- Don't quote the diff back to the author — they wrote it.
