plan-review

# Plan Review

## Overview

Quality gate that validates implementation plans before code execution. Spawns 4 specialized reviewers in parallel, then synthesizes findings into a unified verdict.

**Invoke:** `/review-plan [plan_file]` after `implementation-planning` completes

**Position in workflow:**
```
brainstorming → implementation-planning → plan-review → executing-plans
```

## When to Activate

<example>
User: "I've finished the implementation plan, can you review it?"
Action: Activate - explicit review request
</example>

<example>
User: "Let's check the plan before we start coding"
Action: Activate - pre-execution validation
</example>

<example>
User: "Review docs/plans/2026-02-03-auth-feature.md"
Action: Activate - specific plan review
</example>

<example>
User: "Create an implementation plan for user authentication"
Action: Do NOT activate - use implementation-planning instead
</example>

<example>
User: "Execute the implementation plan"
Action: Do NOT activate - use executing-plans instead
</example>

## Core Philosophy

**Accuracy over speed.** This is a quality gate, not a quick check.

- Extra minutes here save days of rework downstream
- Thorough verification prevents production data loss
- A missed hallucination becomes a runtime error
- A missed security issue becomes a breach
- A missed migration rollback becomes unrecoverable data

**This is a token-intensive operation.** Reserve for high-risk or high-complexity work. For simpler plans, consider a simplified single-reviewer focus.

## The Four Reviewers

Plan review spawns 4 specialized agents in parallel, each with a distinct lens:

### 1. Reality Reviewer
**Focus:** Does the plan match codebase reality?
- Symbol verification (do referenced methods/classes exist?)
- Path validation (do file paths exist and follow conventions?)
- Version compatibility (do library versions match manifest?)
- Convention alignment (does plan follow CLAUDE.md rules?)

**Blocking conditions:** Hallucinated symbols,