| 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
- 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.
- 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.
- 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.
