---

name: code-review-guide description: "Review a pull request or diff like a thoughtful senior engineer — prioritized, kind, and focused on what matters. Use when reviewing code, giving PR feedback, or asked to 'review this change'. Produces a structured review: a correctness/design pass, comments ranked by severity (blocking → nit), what's done well, and a clear approve / request-changes call — feedback that improves the code and the author."

Code Review Guide Skill

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-checklist when you only need a checklist tailored to one change; use ai-code-review when most of the change was written by an AI assistant; use infra-as-code-review when 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:

1. Correctness — does it do what it claims? Edge cases, error handling, off-by-ones, concurrency.
2. Security & data — input validation, authz, secrets, injection, PII handling.
3. Design — is this the right approach? Coupling, the seam, simpler alternative, future pain.
4. Tests — do they cover the behavior and the edges? Would they catch a regression?
5. 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."