<Purpose>
Plan creates comprehensive, actionable work plans through intelligent interaction. It auto-detects whether to interview the user (broad requests) or plan directly (detailed requests), and supports consensus mode (iterative Planner/Architect/Critic loop) and review mode (Critic evaluation of existing plans).
</Purpose>
<Use_When>
- User wants to plan before implementing -- "plan this", "plan the", "let's plan"
- User wants structured requirements gathering for a vague idea
- User wants an existing plan reviewed -- "review this plan",
- User wants multi-perspective consensus on a plan -- , "ralplan"
- Task is broad or vague and needs scoping before any code is written
</Use_When>
<Do_Not_Use_When>
- User wants autonomous end-to-end execution -- use instead
- User wants to start coding immediately with a clear task -- use or delegate to executor
- User asks a simple question that can be answered directly -- just answer it
- Task is a single focused fix with obvious scope -- skip planning, just do it
</Do_Not_Use_When>
<Why_This_Exists>
Jumping into code without understanding requirements leads to rework, scope creep, and missed edge cases. Plan provides structured requirements gathering, expert analysis, and quality-gated plans so that execution starts from a solid foundation. The consensus mode adds multi-perspective validation for high-stakes projects.
</Why_This_Exists>
<Execution_Policy>
- Auto-detect interview vs direct mode based on request specificity
- Ask one question at a time during interviews -- never batch multiple questions
- Gather codebase facts via agent before asking the user about them
- Plans must meet quality standards: 80%+ claims cite file/line, 90%+ criteria are testable
- Consensus mode requires explicit user approval before proceeding to implementation
</Execution_Policy>
<Steps>
Mode Selection
| Mode | Trigger | Behavior |
|---|
| Interview | Default for broad requests | Interactive requirements gathering |
| Direct | , or detailed request | Skip interview, generate plan directly |
| Consensus | , "ralplan" | Planner -> Architect -> Critic loop until agreement |
| Review | , "review this plan" | Critic evaluation of existing plan |
Interview Mode (broad/vague requests)
- Classify the request: Broad (vague verbs, no specific files, touches 3+ areas) triggers interview mode
- Ask one focused question using for preferences, scope, and constraints
- Gather codebase facts first: Before asking "what patterns does your code use?", spawn an agent to find out, then ask informed follow-up questions
- Build on answers: Each question builds on the previous answer
- Consult Analyst (Opus) for hidden requirements, edge cases, and risks
- Create plan when the user signals readiness: "create the plan", "I'm ready", "make it a work plan"
Direct Mode (detailed requests)
- Quick Analysis: Optional brief Analyst consultation
- Create plan: Generate comprehensive work plan immediately
- Review (optional): Critic review if requested
Consensus Mode ( / "ralplan")
- Planner creates initial plan
- Architect reviews for architectural soundness (prefer with role)
- Critic evaluates against quality criteria (prefer with role)
- If Critic rejects: iterate with feedback (max 5 iterations)
- On Critic approval: enter Plan Mode for explicit user consent
- User chooses: Approve (execute), Request changes (re-plan), or Reject (discard)
Review Mode ()
- Read plan file from
- Evaluate via Critic (prefer with role)
- Return verdict: APPROVED, REVISE (with specific feedback), or REJECT (replanning required)
Plan Output Format
Every plan includes:
- Requirements Summary
- Acceptance Criteria (testable)
- Implementation Steps (with file references)
- Risks and Mitigations
- Verification Steps
Plans are saved to
. Drafts go to
.
</Steps>
<Tool_Usage>
- Before first MCP tool use, call to discover deferred MCP tools
- Use for preference questions (scope, priority, timeline, risk tolerance) -- provides clickable UI
- Use plain text for questions needing specific values (port numbers, names, follow-up clarifications)
- Use agent (Haiku, 30s timeout) to gather codebase facts before asking the user
- Use with for planning validation on large-scope plans
- Use with for requirements analysis
- Use with for plan review in consensus and review modes
- If ToolSearch finds no MCP tools or Codex is unavailable, fall back to equivalent Claude agents -- never block on external tools
</Tool_Usage>
<Examples>
<Good>
Adaptive interview (gathering facts before asking):
```
Planner: [spawns explore agent: "find authentication implementation"]
Planner: [receives: "Auth is in src/auth/ using JWT with passport.js"]
Planner: "I see you're using JWT authentication with passport.js in src/auth/.
For this new feature, should we extend the existing auth or add a separate auth flow?"
```
Why good: Answers its own codebase question first, then asks an informed preference question.
</Good>
<Good>
Single question at a time:
```
Q1: "What's the main goal?"
A1: "Improve performance"
Q2: "For performance, what matters more -- latency or throughput?"
A2: "Latency"
Q3: "For latency, are we optimizing for p50 or p99?"
```
Why good: Each question builds on the previous answer. Focused and progressive.
</Good>
<Bad>
Asking about things you could look up:
```
Planner: "Where is authentication implemented in your codebase?"
User: "Uh, somewhere in src/auth I think?"
```
Why bad: The planner should spawn an explore agent to find this, not ask the user.
</Bad>
<Bad>
Batching multiple questions:
```
"What's the scope? And the timeline? And who's the audience?"
```
Why bad: Three questions at once causes shallow answers. Ask one at a time.
</Bad>
<Bad>
Presenting all design options at once:
```
"Here are 4 approaches: Option A... Option B... Option C... Option D... Which do you prefer?"
```
Why bad: Decision fatigue. Present one option with trade-offs, get reaction, then present the next.
</Bad>
</Examples>
<Escalation_And_Stop_Conditions>
- Stop interviewing when requirements are clear enough to plan -- do not over-interview
- In consensus mode, stop after 5 Planner/Architect/Critic iterations and present the best version
- Consensus mode requires explicit user approval before any implementation begins
- If the user says "just do it" or "skip planning", transition to execution mode (ralph or executor)
- Escalate to the user when there are irreconcilable trade-offs that require a business decision
</Escalation_And_Stop_Conditions>
<Final_Checklist>
<Advanced>
## Design Option Presentation
When presenting design choices during interviews, chunk them:
- Overview (2-3 sentences)
- Option A with trade-offs
- [Wait for user reaction]
- Option B with trade-offs
- [Wait for user reaction]
- Recommendation (only after options discussed)
Format for each option:
### Option A: [Name]
**Approach:** [1 sentence]
**Pros:** [bullets]
**Cons:** [bullets]
What's your reaction to this approach?
Question Classification
Before asking any interview question, classify it:
| Type | Examples | Action |
|---|
| Codebase Fact | "What patterns exist?", "Where is X?" | Explore first, do not ask user |
| User Preference | "Priority?", "Timeline?" | Ask user via AskUserQuestion |
| Scope Decision | "Include feature Y?" | Ask user |
| Requirement | "Performance constraints?" | Ask user |
Review Quality Criteria
| Criterion | Standard |
|---|
| Clarity | 80%+ claims cite file/line |
| Testability | 90%+ criteria are concrete |
| Verification | All file refs exist |
| Specificity | No vague terms |
Deprecation Notice
The separate
,
, and
skills have been merged into
. All workflows (interview, direct, consensus, review) are available through
.
</Advanced>