Run a systematic multi-pass code review - correctness, design, security, performance, tests - and report findings ordered by severity with concrete, respectful suggestions. Use when someone asks "review this PR", "review this diff", "what's wrong with this change", or wants a pre-merge quality gate on a branch. Do NOT use for a security-only deep audit of a change - use secure-code-review instead - or for writing the ticket or tracking artifact that describes the change - use jira-ticket-writer instead.
Click to play with sound.
---
name: Code Review Checklist
description: Run a systematic multi-pass code review - correctness, design, security, performance, tests - and report findings ordered by severity with concrete, respectful suggestions. Use when someone asks "review this PR", "review this diff", "what's wrong with this change", or wants a pre-merge quality gate on a branch. Do NOT use for a security-only deep audit of a change - use secure-code-review instead - or for writing the ticket or tracking artifact that describes the change - use jira-ticket-writer instead.
---
# Code Review Checklist
A good review catches the bug before production and leaves the author better at their job; a bad review rubber-stamps the diff or nitpicks formatting while an injection hole ships. This skill turns review into an ordered procedure - separate passes with separate questions - because reading once for everything at once is how correctness bugs hide behind style comments.
## Inputs to collect
Before the first pass, gather: the diff itself, the stated intent (PR description, ticket, or ask the author - reviewing a change without knowing what it claims to do is guessing), and how the change reaches users (user-facing, internal tool, data migration) since that sets the severity bar. Review the change, not the whole codebase: read surrounding context only where the diff demands it.
## Operating procedure
Run the passes in this order. Correctness comes first because a beautifully designed wrong answer is worthless, and security before performance because a fast vulnerability is worse than a slow safe path. Do each pass as a separate read of the diff.
### Pass 1 - Correctness
Does the code do what the PR says it does? Red flags:
- Edge cases unhandled: empty inputs, null/undefined, zero, negative numbers, very large values, unicode, concurrency.
- Errors swallowed silently - an empty catch block or a logged-and-ignored failure is a future 3am page.
- Off-by-one and boundary conditions: `<` vs `<=`, inclusive vs exclusive ranges, first/last iteration.
- The diff and the description disagree - either the code or the claim is wrong; find out which.… install to load the full skill