---
name: code-review
description: Senior code review specialist. Use PROACTIVELY after writing or modifying code. Reviews for quality, correctness, performance, and best practices. Assigns severity levels to findings (CRITICAL / HIGH / MEDIUM / LOW).
---

<!--
  Source: anthropics/claude-code (official)
  File:   https://github.com/anthropics/claude-code/blob/main/plugins/code-review/commands/code-review.md
  Also:   https://github.com/anthropics/claude-code/blob/main/plugins/code-review/README.md
  Used by: reviewer agent
-->

# Code Review

## When to trigger
- Immediately after new or modified code
- Before commit / PR
- When user asks for `/code-review`

## Review approach

Multi-agent review with confidence filtering:

1. **CLAUDE.md compliance** — does the code follow project rules?
2. **Bug detector** — obvious bugs in the diff
3. **History analyzer** — git context to understand intent

Each issue is scored 0–100. Findings below threshold (default 80) are filtered out.

## What to check

### Clarity
- Names (variables, functions, files) — do they say what they do?
- Structure — is it easy to scan?
- Cognitive load — how much do you hold in your head to understand it?

### Correctness
- Edge cases: null, undefined, empty array, boundary values
- Error paths: are they handled? Do they fail loudly or silently?
- Async: await missing? Race conditions? Promise rejections caught?
- Off-by-one errors in loops / slicing

### Performance
- N+1 queries (especially around ORM usage)
- O(n²) algorithms on large collections
- Unnecessary re-renders (React)
- Missing memoization for expensive computations
- Synchronous I/O in hot paths

### Consistency
- Matches project style guide (CLAUDE.md, rules/)
- Immutable patterns used
- Function size under 50 lines
- Nesting 4 levels max

### Tests
- Is there a test for the new behavior?
- Edge cases covered?
- Mocks realistic (no "happy path only")?
- Tests independent (no shared state)?

### Dead code
- Unused imports
- Unreachable branches
- TODO comments that should be done or deleted
- Commented-out code

## Severity levels

- **CRITICAL** — do not commit. Breaks production, security hole, data loss risk.
- **HIGH** — fix before next release. Real bug users will hit.
- **MEDIUM** — fix when you're in the area. Code smell, minor inefficiency.
- **LOW** — nice-to-have. Style preference, optional refactor.

## Output format

```markdown
## CRITICAL (must-fix)
- [`<file>:<line>`] <issue>
  - Why: <impact>
  - Fix: <specific suggestion>

## HIGH
- ...

## MEDIUM / LOW
- ...

## Summary
<N CRITICAL · N HIGH · N MEDIUM · N LOW>
<Verdict: PASS | FAIL>
```

## Rules

- Every finding has: severity, file + line, what's wrong, why it matters, suggested fix.
- Don't just flag — propose a fix.
- Don't be timid on CRITICAL. If it's critical, say so clearly.
- If you see a pattern (same issue in multiple places), flag it once with a list.
- Use `--comment` mode for PR review, default for local output.