Code Reviewer
Perform thorough code reviews covering quality, architecture, and performance aspects.
When to Use
- Reviewing pull requests or code changes
- Auditing codebase quality and maintainability
- Evaluating architecture and design decisions
- Identifying performance issues and bottlenecks
- Checking adherence to coding standards
- Finding code smells and technical debt
Review Process
1. Understand Context
Before reviewing, gather context:
- What is the purpose of this code/change?
- What are the project's conventions? (check CLAUDE.md, .eslintrc, etc.)
- Are there existing patterns to follow?
2. Quality Review
Check for:
- Readability: Clear naming, appropriate comments, logical structure
- Maintainability: Single responsibility, DRY principle, low coupling
- Error handling: Proper try/catch, meaningful error messages
- Edge cases: Null checks, boundary conditions, empty states
- Code smells: Long methods, deep nesting, magic numbers
3. Architecture Review
Evaluate:
- Design patterns: Appropriate use, consistency with codebase
- Dependencies: Minimal coupling, clear interfaces
- Modularity: Components have clear boundaries and responsibilities
- Scalability: Can this handle growth without major rewrites?
- Testability: Is the code easy to unit test?
4. Performance Review
Identify:
- Algorithmic efficiency: Time/space complexity concerns
- Memory management: Leaks, unnecessary allocations
- Render performance: Unnecessary re-renders (React), DOM thrashing
- Network efficiency: N+1 queries, missing caching, payload sizes
- Resource cleanup: Event listeners, subscriptions, intervals
Output Format
Structure your review as:
## Code Review: [File/Component Name]
### Summary
[1-2 sentence overview of the review findings]
### Critical Issues
[Must fix before merge - bugs, security issues, data loss risks]
### Recommendations
[Should fix - quality, performance, maintainability improvements]
### Suggestions
[Nice to have - style preferences, minor optimizations]
### Positive Highlights
[Good patterns worth noting for team learning]
Severity Levels
| Level |
Description |
Action |
| Critical |
Bugs, security vulnerabilities, data corruption risk |
Block merge |
| High |
Performance issues, maintainability problems |
Should fix |
| Medium |
Code smells, minor inefficiencies |
Recommend fix |
| Low |
Style preferences, nitpicks |
Optional |
Review Checklist
See CHECKLIST.md for the complete review checklist.
Examples
See EXAMPLES.md for sample reviews demonstrating proper format and tone.
1---2name: code-reviewer3description: Comprehensive code review for quality, architecture, and performance. Use when reviewing PRs, auditing code quality, checking coding standards, evaluating design patterns, identifying performance bottlenecks, or analyzing technical debt. Triggers on "review", "audit", "analyze code", "check quality", "code smell".4---56# Code Reviewer78Perform thorough code reviews covering quality, architecture, and performance aspects.910## When to Use1112- Reviewing pull requests or code changes13- Auditing codebase quality and maintainability14- Evaluating architecture and design decisions15- Identifying performance issues and bottlenecks16- Checking adherence to coding standards17- Finding code smells and technical debt1819## Review Process2021### 1. Understand Context2223Before reviewing, gather context:24- What is the purpose of this code/change?25- What are the project's conventions? (check CLAUDE.md, .eslintrc, etc.)26- Are there existing patterns to follow?2728### 2. Quality Review2930Check for:31- **Readability**: Clear naming, appropriate comments, logical structure32- **Maintainability**: Single responsibility, DRY principle, low coupling33- **Error handling**: Proper try/catch, meaningful error messages34- **Edge cases**: Null checks, boundary conditions, empty states35- **Code smells**: Long methods, deep nesting, magic numbers3637### 3. Architecture Review3839Evaluate:40- **Design patterns**: Appropriate use, consistency with codebase41- **Dependencies**: Minimal coupling, clear interfaces42- **Modularity**: Components have clear boundaries and responsibilities43- **Scalability**: Can this handle growth without major rewrites?44- **Testability**: Is the code easy to unit test?4546### 4. Performance Review4748Identify:49- **Algorithmic efficiency**: Time/space complexity concerns50- **Memory management**: Leaks, unnecessary allocations51- **Render performance**: Unnecessary re-renders (React), DOM thrashing52- **Network efficiency**: N+1 queries, missing caching, payload sizes53- **Resource cleanup**: Event listeners, subscriptions, intervals5455## Output Format5657Structure your review as:5859```markdown60## Code Review: [File/Component Name]6162### Summary63[1-2 sentence overview of the review findings]6465### Critical Issues66[Must fix before merge - bugs, security issues, data loss risks]6768### Recommendations69[Should fix - quality, performance, maintainability improvements]7071### Suggestions72[Nice to have - style preferences, minor optimizations]7374### Positive Highlights75[Good patterns worth noting for team learning]76```7778## Severity Levels7980| Level | Description | Action |81|-------|-------------|--------|82| Critical | Bugs, security vulnerabilities, data corruption risk | Block merge |83| High | Performance issues, maintainability problems | Should fix |84| Medium | Code smells, minor inefficiencies | Recommend fix |85| Low | Style preferences, nitpicks | Optional |8687## Review Checklist8889See [CHECKLIST.md](CHECKLIST.md) for the complete review checklist.9091## Examples9293See [EXAMPLES.md](EXAMPLES.md) for sample reviews demonstrating proper format and tone.
OneDro1d