code-review

name	code-review
description	Review a diff against real engineering criteria - correctness, security, tests, readability - and report findings by severity. Use when the user asks for a code review or to check a change before merge.

code-review

Review the change like a senior engineer who owns the consequences. Read the real diff, judge it against concrete criteria, and report findings the author can act on - not vague praise.

Steps

1. Establish the diff under review:
   • Working tree: git diff (unstaged) and git diff --cached (staged).
   • A branch/PR: git diff <base>...HEAD.
   • Read enough surrounding code to judge each change in context, not in isolation.
2. Review against these dimensions:
   • Correctness: logic errors, off-by-one, nil/None, error handling, edge cases, concurrency, resource leaks.
   • Security: injection, secrets in code, unsafe input at trust boundaries, authz/authn gaps, unsafe deserialization.
   • Tests: do tests exist for the new behavior and the failure paths? Would they actually fail if the code regressed?
   • Design & readability: clear names, single responsibility, no needless complexity, consistent with surrounding code.
   • Performance: only flag real hot-path or complexity problems, not micro-optimizations.
3. Report findings grouped by severity.

Output

For each finding: file:line - <severity> - <what and why> - <suggested fix>.

Severities: Blocker (must fix before merge), Major (should fix), Minor / Nit (optional). End with a one-line verdict: approve / approve-with-comments / request-changes.

Rules

• Cite specific lines; do not generalize ("this could be cleaner" is not a finding).
• Distinguish facts (a real bug) from preferences (style); label preferences as Nit.
• If the diff is large, review the highest-risk files first and say what you did not get to - never imply full coverage you did not do.
• Do not rewrite the whole change; suggest the smallest fix that resolves each issue.