Code Review Skill
Review code for correctness, security, performance, testing, documentation, and architecture. Produces two outputs:
-
Structured findings for Claude Code to act on
-
REVIEW.md human-readable summary
Review Workflow
- MANDATORY: Use context7 Before Any Code Changes
CRITICAL: Before creating, editing, or suggesting code changes, ALWAYS use context7 to look up current documentation.
When to use context7:
-
Before suggesting fixes or improvements
-
When reviewing library/framework usage
-
Before writing code examples or snippets
-
When uncertain about API behavior or best practices
How to use:
- Resolve library: context7 resolve <library-name>
- Get docs: context7 get-library-docs --library <library> --topic <topic>
Example:
context7 resolve react context7 get-library-docs --library react --topic "useEffect dependencies"
- Determine Review Scope
Identify what's being reviewed:
-
Single file: Review that file
-
Directory: Review all relevant files
-
Diff/PR: Focus on changed lines with surrounding context
-
Entire codebase: Start with entry points, follow dependencies
- Select Review Depth
Choose automatically based on context, or accept user override:
Depth When to Use Focus
Quick Small changes, trivial files, time-sensitive Critical issues only
Standard Most reviews, single files, typical PRs All categories, balanced
Deep Pre-production, security-sensitive, complex systems Exhaustive, security-focused
- Detect Languages and Load References
Identify languages present, then load relevant reference files:
-
R → references/r.md
-
Python → references/python.md
-
JavaScript → references/javascript.md
-
SQL → references/sql.md
-
C++ → references/cpp.md
-
Rust → references/rust.md
-
Go → references/go.md
-
Ansible → references/ansible.md
-
Kubernetes/Kustomize → references/kubernetes.md
-
Dockerfile → references/dockerfile.md
-
Docker Compose → references/docker-compose.md
-
Bash → references/bash.md
- Use context7 MCP for Documentation (MANDATORY)
ALWAYS query context7 when:
-
Reviewing ANY library/framework usage (not just unfamiliar ones)
-
Before suggesting code changes or fixes
-
Checking if APIs are used correctly
-
Verifying deprecated patterns
-
Confirming best practices for specific versions
-
Writing code examples or snippets in review feedback
Process:
-
Identify libraries/frameworks in the code being reviewed
-
Use context7 resolve <library> for each one
-
Use context7 get-library-docs to verify API usage and patterns
-
Only THEN proceed with review findings
Example queries:
-
context7 resolve react then context7 get-library-docs --library react --topic "hooks"
-
context7 resolve tensorflow then context7 get-library-docs --library tensorflow --topic "layers"
-
context7 resolve tidyverse for R tidyverse patterns
-
context7 resolve kubernetes for K8s manifest validation
-
context7 resolve express for Node.js API patterns
Never skip this step - outdated or incorrect documentation can lead to poor review suggestions.
- Spawn Subagents for Parallel Review
Use subagents to parallelize review work:
Language Subagent (one per language detected):
Task: Review [language] code in [files] for idioms, patterns, and language-specific issues. Focus: Style, idioms, language-specific performance, common pitfalls. Reference: Load references/[language].md Output: Structured findings list
Security Subagent:
Task: Analyze [files] for security vulnerabilities. Focus: Injection, auth issues, secrets exposure, unsafe operations, dependency risks. Output: Security findings with severity and remediation
Architecture Subagent:
Task: Review overall structure and design of [files/project]. Focus: Coupling, cohesion, separation of concerns, design patterns, testability. Output: Architecture findings and recommendations
- Review Categories
Each category produces findings with severity ratings.
Correctness
-
Logic errors and bugs
-
Edge cases not handled
-
Off-by-one errors
-
Null/undefined handling
-
Type mismatches
-
Race conditions
Security
-
Injection vulnerabilities (SQL, command, XSS)
-
Authentication/authorization flaws
-
Secrets in code
-
Unsafe deserialization
-
Path traversal
-
Dependency vulnerabilities
Performance
-
Algorithmic complexity issues
-
Unnecessary allocations
-
N+1 queries
-
Missing caching opportunities
-
Blocking operations
-
Memory leaks
Testing
-
Missing test coverage
-
Untested edge cases
-
Brittle tests
-
Missing integration tests
-
Inadequate mocking
Documentation
-
Missing function/class docstrings
-
Outdated comments
-
Unclear variable names
-
Missing README updates
-
Undocumented public APIs
Architecture
-
Tight coupling
-
God objects/functions
-
Circular dependencies
-
Layer violations
-
Missing abstractions
-
Poor separation of concerns
- Classify Findings
Rate each finding:
Severity Definition Action
Critical Security vulnerability, data loss risk, crash in production Must fix before merge
Major Significant bug, performance issue, maintainability blocker Should fix before merge
Minor Code smell, style issue, minor inefficiency Fix when convenient
Nitpick Preference, very minor style, optional improvement Consider fixing
- Generate Outputs
Output 1: Claude Code Action Format
Produce structured findings Claude Code can act on directly:
File: [filepath]
[Line X-Y]: [Brief title]
Severity: Critical|Major|Minor|Nitpick Category: Correctness|Security|Performance|Testing|Documentation|Architecture
Issue: [Clear description of the problem]
Current code: [relevant code snippet]
Suggested fix: [corrected code snippet]
Rationale: [Why this change improves the code]
Group findings by file, ordered by severity (Critical first).
Output 2: REVIEW.md Human Summary
Write to REVIEW.md in the project root:
Code Review Summary
Reviewed: [files/scope] Depth: Quick|Standard|Deep Date: [timestamp]
Overview
[2-3 sentence summary of overall code quality and key concerns]
Findings by Severity
Critical ([count])
- [one-line summary with file:line reference]
Major ([count])
- [one-line summary with file:line reference]
Minor ([count])
- [one-line summary with file:line reference]
Nitpicks ([count])
- [one-line summary with file:line reference]
Category Breakdown
| Category | Critical | Major | Minor | Nitpick |
|---|---|---|---|---|
| Correctness | X | X | X | X |
| Security | X | X | X | X |
| Performance | X | X | X | X |
| Testing | X | X | X | X |
| Documentation | X | X | X | X |
| Architecture | X | X | X | X |
Recommendations
[Prioritized list of recommended actions]
Positive Observations
[Things done well - important for balanced feedback]
- Iterate on Critical/Major Issues
After generating outputs:
-
Use context7 to verify fix approaches before implementing
-
If user confirms, apply fixes for Critical and Major issues
-
Re-review changed code to verify fixes don't introduce new issues
-
Update REVIEW.md with resolution status
REMINDER: Use context7 to look up correct API usage before suggesting or implementing any code changes.