plan

<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”, --review
• User wants multi-perspective consensus on a plan — --consensus, “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 autopilot instead
• User wants to start coding immediately with a clear task — use ralph 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 explore 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>

Mode Selection

Interview Mode (broad/vague requests)

1. Classify the request: Broad (vague verbs, no specific files, touches 3+ areas) triggers interview mode
2. Ask one focused question using AskUserQuestion for preferences, scope, and constraints
3. Gather codebase facts first: Before asking “what patterns does your code use?”, spawn an explore agent to find out, then ask informed follow-up questions
4. Build on answers: Each question builds on the previous answer
5. Consult Analyst (Opus) for hidden requirements, edge cases, and risks
6. Create plan when the user signals readiness: “create the plan”, “I’m ready”, “make it a work plan”

Direct Mode (detailed requests)

1. Quick Analysis: Optional brief Analyst consultation
2. Create plan: Generate comprehensive work plan immediately
3. Review (optional): Critic review if requested

Consensus Mode (--consensus / “ralplan”)

1. Planner creates initial plan
2. Architect reviews for architectural soundness (prefer ask_codex with architect role)
3. Critic evaluates against quality criteria (prefer ask_codex with critic role)
4. If Critic rejects: iterate with feedback (max 5 iterations)
5. On Critic approval: enter Plan Mode for explicit user consent
6. User chooses: Approve (execute), Request changes (re-plan), or Reject (discard)

Review Mode (--review)

1. Read plan file from .omc/plans/
2. Evaluate via Critic (prefer ask_codex with critic role)
3. 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 .omc/plans/. Drafts go to .omc/drafts/.

<Tool_Usage>

• Before first MCP tool use, call ToolSearch("mcp") to discover deferred MCP tools
• Use AskUserQuestion 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 explore agent (Haiku, 30s timeout) to gather codebase facts before asking the user
• Use ask_codex with agent_role: "planner" for planning validation on large-scope plans
• Use ask_codex with agent_role: "analyst" for requirements analysis
• Use ask_codex with agent_role: "critic" 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>

<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>

• Plan has testable acceptance criteria (90%+ concrete)
• Plan references specific files/lines where applicable (80%+ claims)
• All risks have mitigations identified
• No vague terms without metrics (“fast” -> “p99 < 200ms”)
• Plan saved to .omc/plans/
• In consensus mode: user explicitly approved before any execution </Final_Checklist>

When presenting design choices during interviews, chunk them:

1. Overview (2-3 sentences)
2. Option A with trade-offs
3. [Wait for user reaction]
4. Option B with trade-offs
5. [Wait for user reaction]
6. 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:

Review Quality Criteria

Deprecation Notice

The separate /planner, /ralplan, and /review skills have been merged into /plan. All workflows (interview, direct, consensus, review) are available through /plan.