Review the current plan thoroughly before making any code changes. For every issue or recommendation, explain the concrete tradeoffs, give an opinionated recommendation, and ask for user input before assuming a direction.
Engineering preferences
Use these to guide your recommendations (override with project-specific CLAUDE.md preferences if they exist):
- DRY is important: flag repetition aggressively
- Well-tested code is non-negotiable: prefer too many tests over too few
- Code should be "engineered enough": not under-engineered (fragile, hacky) and not over-engineered (premature abstraction, unnecessary complexity)
- Err on the side of handling more edge cases, not fewer
- Bias toward explicit over clever; thoughtfulness over speed
Review pipeline
Work through each section sequentially. After each section, pause and ask for feedback before moving on.
1. Architecture review
Evaluate:
- Overall system design and component boundaries
- Dependency graph and coupling concerns
- Data flow patterns and potential bottlenecks
- Scaling characteristics and single points of failure
- Security architecture (auth, data access, API boundaries)
2. Code quality review
Evaluate:
- Code organization and module structure
- DRY violations (be aggressive here)
- Error handling patterns and missing edge cases (call these out explicitly)
- Technical debt hotspots
- Areas that are over-engineered or under-engineered relative to engineering preferences
3. Test review
Evaluate:
- Test coverage gaps (unit, integration, e2e)
- Test quality and assertion strength
- Missing edge case coverage (be thorough)
- Untested failure modes and error paths
4. Performance review
Evaluate:
- N+1 queries and database access patterns
- Memory-usage concerns
- Caching opportunities
- Slow or high-complexity code paths
Issue reporting format
For every specific issue found (bug, smell, design concern, or risk):
- Describe the problem concretely, with file and line references
- Present 2-3 options, including "do nothing" where that's reasonable
- For each option, specify: implementation effort, risk, impact on other code, and maintenance burden
- Give your recommended option and why, mapped to engineering preferences above
- Ask explicitly whether the user agrees or wants to choose a different direction before proceeding
Workflow
- Do not assume priorities on timeline or scale
- After each section, pause and ask for feedback before moving on
- Use AskUserQuestion for structured option selection
Before starting
Ask if the user wants one of two options:
- BIG CHANGE: Work through this interactively, one section at a time (Architecture → Code Quality → Tests → Performance) with at most 4 top issues in each section
- SMALL CHANGE: Work through interactively ONE question per review section
Tips
- Combine with
.claude/rules/files for project-specific review criteria - Engineering preferences above can be overridden by your project's CLAUDE.md
- For deeper analysis, use this command with Opus model
Sources
- Inspired by Garry Tan's Plan Mode prompt (Feb 2026)
- Adapted for Claude Code's native config system
$ARGUMENTS