plan

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

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

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

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

<Steps>

• Requirements Summary
• Acceptance Criteria (testable)
• Implementation Steps (with file references)
• Risks and Mitigations
• Verification Steps

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

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

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

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

<Advanced>

.omc/plans/

.omc/drafts/

Planner: [启动explore agent: "查找认证实现位置"]
Planner: [收到回复: "认证在src/auth/中使用JWT和passport.js实现"]
Planner: "我了解到你的代码库在src/auth/中使用JWT和passport.js实现认证。
         对于这个新功能，我们应该扩展现有认证体系还是添加独立的认证流程？"

问题1: "主要目标是什么？"
回答1: "提升性能"
问题2: "关于性能，你更关注延迟还是吞吐量？"
回答2: "延迟"
问题3: "关于延迟，我们是针对p50还是p99进行优化？"

Planner: "你的代码库中认证功能在哪里实现？"
用户: "呃，我想是在src/auth的某个地方？"

"范围是什么？时间线呢？受众是谁？"

"这里有4种方案：方案A... 方案B... 方案C... 方案D... 你偏好哪一种？"

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)

undefined

undefined