Bad code review nitpicks style while missing the design flaw, or dumps 40 ungraded comments. Good review is prioritized and kind: it catches what actually matters (correctness, security, design), separates blocking issues from nits, explains the why, and leaves the author better. This skill runs that review.
Not quite this? Use
code-review-checklistwhen you only need a checklist tailored to one change; useai-code-reviewwhen most of the change was written by an AI assistant; useinfra-as-code-reviewwhen the change is Terraform, CloudFormation or other infrastructure code.
Required Inputs
Ask for these only if they aren't already provided:
- The change — the diff/PR, and ideally its description/intent (what it's trying to do).
- Context — language/stack, conventions, the part of the system it touches, risk level.
- Focus (optional) — anything specific to scrutinize (security, performance, a tricky area).
Output Format
Review: [PR / change]
Summary — in 1–2 lines: what the change does and your overall read (solid / needs work / risky).
Review passes — scan in priority order and note findings:
- Correctness — does it do what it claims? Edge cases, error handling, off-by-ones, concurrency.
- Security & data — input validation, authz, secrets, injection, PII handling.
- Design — is this the right approach? Coupling, the seam, simpler alternative, future pain.
- Tests — do they cover the behavior and the edges? Would they catch a regression?
- Readability — names, clarity, dead code, docs where non-obvious.
Comments (ranked by severity) — each with file/line, the issue, why it matters, and a concrete suggestion:
| Severity | Where | Comment & why | Suggested change |
|---|---|---|---|
| 🔴 Blocking | |||
| 🟡 Should-fix | |||
| 🔵 Nit / optional |
What's done well — genuinely (specific, not flattery). Reviews are also for morale and learning.
Verdict — ✅ Approve / 🔁 Request changes / 💬 Comment — with the one or two things that gate it.
Quality Checks
- Correctness, security, and design are reviewed before style — priority order
- Comments are ranked by severity (blocking vs. should-fix vs. nit), not a flat list
- Each comment explains why and offers a concrete suggestion, not just "this is wrong"
- At least one specific thing done well is noted
- A clear verdict (approve / request changes) with the gating issues named
- Tone is direct but kind — critiques the code, not the author
Anti-Patterns
- Do not nitpick style while missing a correctness or security problem — priority first
- Do not dump ungraded comments — rank them so the author knows what's blocking
- Do not say "this is wrong" without why and a suggested fix
- Do not rewrite it your way for taste — respect working approaches; flag real issues
- Do not be a jerk — review the code, acknowledge good work, keep the author motivated
Based On
Senior code-review practice (Google's engineering review guidelines): prioritize correctness/design, severity-tag feedback, be kind.
Example Trigger Phrases
- "Review code."
- "Give PR feedback."
- "Review this change."