---

name: code-reviewer description: Expert code review skill for auditing code quality, security, performance, and maintainability. Use when (1) reviewing pull requests or code changes, (2) auditing existing code for issues, (3) validating code before production deployment, (4) checking for security vulnerabilities, (5) assessing performance bottlenecks, (6) ensuring adherence to SOLID/DRY/KISS principles, or (7) the user explicitly requests a "code review" or "audit".

Code Reviewer

A rigorous, multi-dimensional code review skill that transforms code auditing into a systematic, production-grade process.

Review Process

Code review involves these sequential steps:

1. Understand Context → Determine what the code does and its purpose
2. Select Review Type → Choose the appropriate review focus (see below)
3. Execute Review → Apply the relevant checklists systematically
4. Generate Report → Produce actionable findings with severity ratings

Review Types

Determine the appropriate review type based on user request:

Core Review Dimensions

1. Correctness & Logic

• Does the code do what it claims to do?
• Are edge cases handled (null, empty, boundary values)?
• Is error handling comprehensive and appropriate?
• Are there any logic flaws or race conditions?

2. Security (See security-checklist.md)

• Input validation and sanitization
• Authentication/Authorization flaws
• Injection vulnerabilities (SQL, XSS, Command)
• Secrets and credential exposure
• Dependency vulnerabilities

3. Performance (See performance-checklist.md)

• Algorithm complexity (time/space)
• Database query efficiency (N+1, missing indexes)
• Memory leaks and resource management
• Caching opportunities
• Async/blocking operations

4. Maintainability (See maintainability-checklist.md)

• SOLID principles adherence
• DRY (Don't Repeat Yourself)
• KISS (Keep It Simple, Stupid)
• Code readability and naming
• Documentation and comments

5. Type Safety & Contracts

• Type annotations present and correct
• Null/undefined handling
• API contract consistency
• Schema validation

Severity Classification

Rate each finding using this severity scale:

Report Format

Generate review reports using this structure:

Copy# Code Review Report

## Summary
- **Files Reviewed:** [count]
- **Critical Issues:** [count]
- **High Issues:** [count]
- **Medium Issues:** [count]
- **Low Issues:** [count]

## Critical & High Priority Findings

### 🔴 [Finding Title]
**File:** `path/to/file.py` (Line X-Y)
**Category:** [Security/Performance/Correctness/Maintainability]
**Issue:** [Clear description of the problem]
**Impact:** [What could go wrong]
**Recommendation:** [How to fix with code example if applicable]

## Medium & Low Priority Findings

### 🟡 [Finding Title]
[Same structure as above]

## Positive Observations
- [What was done well]

## Recommendations Summary
1. [Priority-ordered action items]

Language-Specific Patterns

Apply language-specific checks when reviewing:

Python

• Type hints present (def foo(x: int) -> str:)
• Proper exception handling (avoid bare except:)
• Context managers for resources (with open()...)
• Avoid mutable default arguments
• Use pathlib over string path manipulation

TypeScript/JavaScript

• Strict null checks
• Proper async/await error handling
• Avoid any type abuse
• Use optional chaining (?.) and nullish coalescing (??)
• Proper event listener cleanup

SQL/Database

• Parameterized queries (never string interpolation)
• Index usage for filtered/joined columns
• Avoid SELECT * in production code
• Transaction boundaries for related operations

Quick Review Checklist

For rapid reviews, use this condensed checklist:

Copy□ Does it work correctly for the happy path?
□ Are edge cases and errors handled?
□ Is user input validated and sanitized?
□ Are there any hardcoded secrets or credentials?
□ Is the algorithm efficient enough for expected scale?
□ Will this code be understandable in 6 months?
□ Are dependencies up-to-date and necessary?
□ Is there adequate test coverage?

Anti-Patterns to Flag

Immediately flag these common anti-patterns: