Code Review Checklist Skill

A Claude Code skill that provides a systematic, comprehensive checklist for conducting thorough code reviews — covering correctness, security, performance, readability, testing, and architectural alignment.

When to Use This Skill

Choose this skill when:

• Reviewing pull requests before merging to main
• Conducting peer code reviews on teammate's changes
• Performing self-review before submitting your own PR
• Auditing critical code paths (payments, auth, data handling)
• Onboarding reviewers who need a structured review process
• Establishing code review standards for a new team

Consider alternatives when:

• You need automated static analysis (use ESLint, SonarQube, or similar)
• You need security-focused reviews only (use the security review skill)
• You need performance profiling (use profiling tools, not code review)

Quick Start

Copy
# Add to your Claude Code project
claude mcp add code-review-checklist

# Review a pull request
claude "review PR #42 using the code review checklist"

# Review specific files
claude "run code review checklist on src/services/paymentService.ts"

Copy
# .claude/skills/code-review-checklist.yml
name: code-review-checklist
description: Systematic code review with comprehensive checklist
triggers:
  - "code review"
  - "review checklist"
  - "pr review"
config:
  depth: standard
  focus_areas: all
  output_format: checklist

Core Concepts

Review Categories

Category	Focus Area	Priority
Correctness	Logic errors, edge cases, error handling	Critical
Security	Input validation, auth, injection, secrets	Critical
Performance	N+1 queries, memory leaks, unnecessary computation	High
Readability	Naming, structure, comments, complexity	High
Testing	Coverage, edge cases, test quality	High
Architecture	Separation of concerns, patterns, coupling	Medium
Compatibility	Breaking changes, migration, backwards compat	Medium
Documentation	API docs, changelog, inline explanations	Low

Review Checklist Template

Copy
## Correctness
- [ ] Logic handles all expected input cases correctly
- [ ] Edge cases are handled (null, empty, boundary values)
- [ ] Error paths return appropriate errors, not silent failures
- [ ] Async operations have proper error handling and cleanup
- [ ] State mutations are intentional and well-controlled

## Security
- [ ] User input is validated and sanitized before use
- [ ] No SQL/NoSQL injection vulnerabilities
- [ ] Authentication and authorization checks are present
- [ ] No hardcoded secrets or credentials
- [ ] Sensitive data is not logged or exposed in errors

## Performance
- [ ] No N+1 database query patterns
- [ ] Large data sets use pagination or streaming
- [ ] Expensive operations are cached where appropriate
- [ ] No unnecessary re-renders or re-computations
- [ ] Database queries use appropriate indexes

## Readability
- [ ] Variable and function names are descriptive
- [ ] Functions have a single, clear responsibility
- [ ] Complex logic has explanatory comments
- [ ] Code follows existing project conventions
- [ ] No dead code or commented-out blocks

Review Severity Levels

Copy
🔴 **Blocker** — Must fix before merge. Security vulnerability,
   data loss risk, or broken functionality.

🟡 **Warning** — Should fix before merge. Performance issue,
   missing validation, or poor error handling.

🔵 **Suggestion** — Nice to have. Readability improvement,
   minor refactoring, or style preference.

⚪ **Note** — Informational. Explanation of a pattern,
   alternative approach, or future consideration.

Configuration

Parameter	Type	Default	Description
depth	string	"standard"	Review depth: quick, standard, thorough
focus_areas	string	"all"	Categories to check: all, security, performance, readability
output_format	string	"checklist"	Output format: checklist, narrative, json
severity_threshold	string	"suggestion"	Minimum severity to report: blocker, warning, suggestion, note
max_findings	number	20	Maximum findings to report per review
include_praise	boolean	true	Include positive feedback on well-written code
auto_approve	boolean	false	Auto-approve if no blockers or warnings found

Best Practices

1. Start with the PR description and overall diff before diving into files — understand the intent and scope of the change before reviewing individual lines; this prevents nitpicking details while missing architectural problems.

2. Prioritize blockers over style preferences — a security vulnerability matters more than a naming convention; focus review effort on issues that could cause incidents, data loss, or security breaches.

3. Provide actionable feedback with examples — instead of "this could be better," show what better looks like with a code suggestion; reviewers who provide concrete alternatives get faster responses.

4. Review tests alongside implementation — check that tests actually verify the behavior being changed, not just that they exist; tests that pass trivially or test the wrong thing provide false confidence.

5. Limit review sessions to 60 minutes or 400 lines — code review effectiveness drops sharply after reviewing large diffs; for big PRs, ask the author to split into smaller, reviewable chunks.

Common Issues

Reviews take too long and block PRs — Set a team SLA for review turnaround (e.g., 24 hours). Use the depth: quick mode for small changes and reserve thorough mode for critical paths like authentication or payment processing.

Reviewers focus on style instead of substance — Configure linters and formatters to catch style issues automatically so human reviewers can focus on logic, architecture, and security. If your team argues about style in reviews, the answer is usually "add a lint rule."

Same issues keep appearing in reviews — Track recurring review findings and convert them into automated checks (lint rules, pre-commit hooks, or CI checks). If you're flagging the same pattern in every review, it should be automated.