home / skills / laurigates / claude-plugins / code-review-checklist

This skill guides structured code reviews by applying security, correctness, performance, and quality checks across projects to improve reliability.

npx playbooks add skill laurigates/claude-plugins --skill code-review-checklist

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
3.3 KB
---
model: opus
name: code-review-checklist
description: Structured code review approach covering security, quality, performance, and consistency.
allowed-tools: Read, Grep, Glob
created: 2025-12-27
modified: 2025-12-27
reviewed: 2025-12-27
---

# Code Review Checklist

Structured approach to reviewing code changes.

## Review Priority Order

1. **Security** (Critical) - Vulnerabilities, secrets, injection
2. **Correctness** (High) - Logic errors, breaking changes
3. **Performance** (Medium) - Inefficiencies, resource leaks
4. **Quality** (Medium) - Maintainability, readability
5. **Style** (Low) - Formatting, naming (should be automated)

## Security Checklist

### Secrets & Credentials
- [ ] No hardcoded API keys, passwords, tokens
- [ ] No credentials in logs or error messages
- [ ] Secrets loaded from environment/vault

### Injection Vulnerabilities
- [ ] SQL queries use parameterized statements
- [ ] User input is sanitized before HTML output (XSS)
- [ ] Shell commands don't include user input (command injection)
- [ ] File paths are validated (path traversal)

### Authentication & Authorization
- [ ] Auth checks on all protected endpoints
- [ ] Proper session handling
- [ ] Secure password handling (hashing, not plaintext)

### Data Exposure
- [ ] Sensitive data not logged
- [ ] API responses don't leak internal details
- [ ] Error messages don't expose system info

## Correctness Checklist

### Logic
- [ ] Edge cases handled (null, empty, boundary values)
- [ ] Error conditions handled appropriately
- [ ] Async operations properly awaited
- [ ] Race conditions considered

### Breaking Changes
- [ ] API contracts maintained
- [ ] Database migrations are reversible
- [ ] Feature flags for risky changes

### Testing
- [ ] New code has tests
- [ ] Tests cover error paths, not just happy path
- [ ] Existing tests still pass

## Performance Checklist

### Efficiency
- [ ] No N+1 queries
- [ ] Appropriate data structures used
- [ ] No unnecessary loops or iterations
- [ ] Caching considered for expensive operations

### Resources
- [ ] Database connections closed/pooled
- [ ] File handles closed
- [ ] No memory leaks (event listeners removed, etc.)

### Scale
- [ ] Works with realistic data volumes
- [ ] Pagination for large result sets
- [ ] Timeouts on external calls

## Quality Checklist

### Readability
- [ ] Clear, descriptive names
- [ ] Functions do one thing
- [ ] No overly complex conditionals
- [ ] Comments explain "why", not "what"

### Maintainability
- [ ] DRY (no copy-paste duplication)
- [ ] Appropriate abstractions
- [ ] Dependencies are justified
- [ ] No dead code

### Consistency
- [ ] Follows project patterns
- [ ] Matches existing code style
- [ ] Uses established utilities/helpers

## Review Output Format

```markdown
## Review: [PR Title]

**Risk Level**: LOW | MEDIUM | HIGH | CRITICAL

### Critical Issues
1. [Category] Description (file:line)
   - Impact: What could go wrong
   - Fix: Specific recommendation

### Suggestions
1. [Category] Description (file:line)
   - Why: Reasoning
   - Consider: Alternative approach

### Positive Notes
- [Recognition of good patterns]
```

## Quick Checks

For fast reviews, at minimum check:
1. Any secrets or credentials?
2. Any SQL/command injection?
3. Are error cases handled?
4. Do tests exist for new code?

Overview

This skill provides a structured code review checklist focused on security, correctness, performance, quality, and style to help reviewers find high-impact issues quickly. It standardizes output and risk communication so reviews are consistent and actionable. The checklist is lightweight and optimized for fast or in-depth reviews in development workflows.

How this skill works

The skill guides reviewers through a prioritized list: Security first (critical), then Correctness, Performance, Quality, and finally Style. It inspects common risk areas such as hardcoded secrets, injection vectors, edge-case handling, resource leaks, and maintainability problems. Output is formatted into a concise review report with risk level, critical issues, suggestions, and positive notes.

When to use it

  • During pull request reviews before merging significant or risky changes
  • As a quick gate for continuous integration or pre-merge checks
  • When onboarding reviewers to a consistent review standard
  • Before releases or deployments to catch regressions
  • When auditing third-party or contributed code for safety and correctness

Best practices

  • Prioritize security and critical correctness items before style nitpicks
  • Automate style and simple checks (linters, formatters) to keep review scope focused
  • Reference concrete file:line examples and provide explicit fixes in comments
  • Use feature flags and reversible migrations for risky changes
  • Include or update tests covering error paths and boundary cases

Example use cases

  • Review a backend API change for injection risks, auth checks, and response exposure
  • Evaluate a database migration for reversibility, performance impacts, and test coverage
  • Perform a fast CI-assisted review that checks for secrets, basic injection, and presence of tests
  • Audit a performance-sensitive function for N+1 queries, caching opportunities, and resource handling
  • Validate frontend changes for XSS, input sanitization, and correct error handling

FAQ

What are the highest-priority checks?

Security checks (secrets, injection, auth) are highest. Next come correctness checks for logic and breaking changes.

How should style issues be handled?

Automate formatting and naming where possible. Reserve human review for consistency or pattern mismatches that linters can't catch.

What quick checks can I run for a fast review?

At minimum: look for secrets/credentials, SQL/command injection, error handling, and tests for new code.