code-review

name	code-review
description	Review completed changes for blockers, regressions, security, and scope drift. Use with /code-review before merge or final handoff.

Code Review

Use /code-review before merge or final handoff.

When to use

• Changes are complete and ready for review
• You need a second opinion before shipping
• You want to catch regressions, security issues, or scope drift

Steps

1. Read the diff — git diff for unstaged, git diff --staged for staged, or git diff main...HEAD for branch diff
2. Check for blockers — bugs, logic errors, missing error handling, broken contracts
3. Check for security — secrets in code, injection risks, auth gaps, unsafe defaults, and data exposure / least privilege: does the change return, log, or expose more than it needs (PII, password hashes, SELECT *, tokens, internal fields)?
4. Check for regressions — does the change break existing tests or documented behaviour?
5. Check for scope drift — does the change do more or less than requested?
6. Run tests if they exist and haven't been run

Rules

• Don't stop at the first issue. Once you find a blocker, keep scanning the whole change — a serious bug (e.g. a data leak) often hides behind the obvious one. Review every line.
• Only flag issues that genuinely matter — no style nits, no formatting opinions
• If the code works, tests pass, and scope is right, say so clearly
• Flag anything you'd reject in a PR review

Output

• Verdict — PASS / NEEDS_CHANGES / BLOCKER
• Blocking — issues that must be fixed before merge
• Non-blocking — suggestions or observations
• Evidence reviewed — what was checked (diff, tests, build)