replan

Plan Review (/replan)

You have a plan in the current conversation (or at a file path the user provides). Your job is to validate it thoroughly by dispatching parallel review subagents, then update the plan based on their findings.

Announce: "Reviewing the plan with parallel subagents..."

Step 1: Understand the Plan

Read the plan carefully. Identify:

• Type of plan: implementation, research, design, migration, refactor, etc.
• Key domains it touches: backend, frontend, database, API, design, infrastructure, external services, etc.
• Specific technologies and files mentioned
• Assumptions the plan makes (explicit and implicit)

Step 2: Design Review Agents

Based on what the plan actually covers, decide which review perspectives are needed. The goal is full coverage of the plan's scope — not a fixed set of agents.

Pick from these perspectives (and invent new ones if the plan demands it):

Perspective	When to use	What it checks
Codebase alignment	Always for code-touching plans	Do referenced files/functions/APIs actually exist? Does the plan match current code structure and patterns? Are there existing utilities it should reuse?
Best practices & architecture	Always for code-touching plans	SOLID, DRY, YAGNI, separation of concerns, error handling, security (OWASP top 10), performance implications
Project standards	When CLAUDE.md / linting / conventions exist	Naming conventions, file structure patterns, test conventions, commit style, tech stack alignment
Feasibility & risks	Always	Missing steps, implicit dependencies between tasks, ordering issues, underestimated complexity, things that could block execution
Fresh perspective	Always — this is the wildcard	An agent that reads the plan cold and asks "what's missing that nobody thought of?" — edge cases, user experience gaps, operational concerns, things the plan author's tunnel vision missed
Research & fact-checking	Plans involving external APIs, libs, protocols	Are the APIs/libraries/versions referenced real and current? Do they work the way the plan assumes?
Design & UX	Plans with UI/visual components	Visual consistency, accessibility, responsive behavior, interaction patterns, loading/error states
Data & schema	Plans touching databases or data models	Migration safety, backwards compatibility, indexing, data integrity, query performance
Security	Plans touching auth, user input, APIs	Authentication/authorization flows, input validation, secrets handling, attack surface
Operations	Plans touching infra, deployment, monitoring	Rollback strategy, monitoring gaps, configuration management, failure modes

Rules for agent count:

• Minimum 3 agents (even for simple plans — codebase alignment + feasibility + fresh perspective)
• Always include the fresh perspective agent — it consistently catches things others miss
• Scale with plan complexity: a 3-task plan might need 3-4 agents, a 15-task plan might need 6-8
• Each agent should have a distinct, non-overlapping focus area
• If you're unsure whether a perspective is needed, include it — over-reviewing is better than missing something

Step 3: Dispatch All Agents in Parallel

Launch all review agents simultaneously using the Agent tool. Each agent gets:

1. The complete plan text (copy it in full — agents don't have your conversation context)
2. Relevant codebase context — for codebase alignment agents, include file paths to check. For standards agents, include CLAUDE.md content.
3. A specific review mandate — what exactly to look for
4. Output format — structured findings

Agent Prompt Template

Each agent should receive a prompt structured like this:

You are reviewing an implementation plan from the perspective of [PERSPECTIVE].

## The Plan
[FULL PLAN TEXT]

## Your Review Mandate
[SPECIFIC INSTRUCTIONS FOR THIS PERSPECTIVE]

## Project Context
[RELEVANT CONTEXT: CLAUDE.md contents, file paths, tech stack, etc.]

## Output Format
Return your review as:

### [PERSPECTIVE] Review

**Verdict: PASS | ISSUES FOUND | CONCERNS**

**Critical Issues** (must fix before execution):
- [issue]: [why it matters] → [suggested fix]

**Recommendations** (should fix, but not blocking):
- [recommendation]: [why it matters] → [suggested approach]

**Observations** (informational, no action needed):
- [observation]

If everything looks good, say PASS and briefly explain why the plan is solid from your perspective.

For the fresh perspective agent specifically, use this framing:

You are reviewing this plan with completely fresh eyes. You haven't been part of any discussion about it. Read it cold and ask yourself:

- What would go wrong that nobody anticipated?
- What's missing that seems obvious once you think about it?
- Are there simpler alternatives to any of the proposed approaches?
- What will the person executing this plan wish they'd known upfront?
- Are there edge cases, error states, or user scenarios the plan ignores?

Be constructively critical. The goal is to find the blind spots.

Step 4: Synthesize and Update the Plan

Once all agents return:

1. Collect all findings — read every agent's review
2. Categorize by severity:
   • Critical: Must be fixed — wrong assumptions, missing steps, security holes, references to non-existent code
   • Important: Should be fixed — better approaches, missing error handling, overlooked edge cases
   • Minor: Nice to have — style suggestions, optional improvements
3. Present a summary to the user: which agents found what, critical issues first
4. Update the plan directly — incorporate all critical and important findings. For minor items, use your judgment.
5. Note what changed — after updating, briefly list the key changes made so the user knows what was improved

The plan should be noticeably better after this process. If agents found nothing critical, that's a good sign — say so.

Adapting to Plan Type

The beauty of this approach is that it adapts to whatever the plan contains:

• Research plan? → Dispatch fact-checking agents that verify sources, check if referenced tools/APIs exist, validate methodology
• Design plan? → Dispatch agents that check visual consistency, load reference images/designs if paths are provided, verify component library usage
• Migration plan? → Dispatch agents focused on rollback safety, data integrity, backwards compatibility, downtime estimation
• Refactor plan? → Dispatch agents that verify test coverage exists for affected code, check for hidden consumers, validate that the refactor actually simplifies things

Read the plan. Think about what could go wrong. Design agents to catch those things.