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 interview rounds into one question form
• Gather codebase facts via explore agent before asking the user about them
• When session guidance enables USE_OMX_EXPLORE_CMD, prefer omx explore for simple read-only repository lookups during planning; keep prompts narrow and concrete, and keep prompt-heavy or ambiguous planning work on the richer normal path and fall back normally if omx explore is unavailable.
• Plans must meet quality standards: 80%+ claims cite file/line, 90%+ criteria are testable
• Implementation step count must be right-sized to task scope; avoid defaulting to exactly five steps when the work is clearly smaller or larger
• Consensus mode outputs the final plan by default; add --interactive to enable execution handoff
• Consensus mode uses RALPLAN-DR short mode by default; switch to deliberate mode with --deliberate or when the request explicitly signals high risk (auth/security, data migration, destructive/irreversible changes, production incident, compliance/PII, public API breakage)
• Apply the shared workflow guidance pattern: outcome-first framing, concise visible updates for multi-step planning, local overrides for the active workflow branch, evidence-backed planning and validation expectations, explicit stop rules, and automatic continuation for safe reversible steps. Ask only for material, destructive, credentialed, external-production, or preference-dependent branches. </Execution_Policy>

Mode Selection

Mode	Trigger	Behavior
Interview	Default for broad requests	Interactive requirements gathering
Direct	--direct, or detailed request	Skip interview, generate plan directly
Consensus	--consensus, "ralplan"	Planner -> Architect -> Critic loop until agreement with RALPLAN-DR structured deliberation (short by default, --deliberate for high-risk); outputs plan by default
Consensus Interactive	--consensus --interactive	Same as Consensus but pauses for user feedback at draft and approval steps, then hands off to execution
Review	--review, "review this plan"	Critic evaluation of existing plan