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 with RALPLAN-DR structured deliberation) 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", --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 -- use an execution skill instead of running it from this planning module </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 runs fully automated by default; add --interactive to enable user prompts at draft review and final approval steps
• 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)
• Planning/execution boundary: planning modes inspect context and produce plans/specs/proposals only. They MUST mark artifacts as pending approval unless the user has explicitly opted into execution in the current turn or via the structured approval UI. Before explicit execution approval, planning modes MUST NOT run mutation-oriented shell commands, edit source files, commit, push, open PRs, invoke execution skills, or delegate implementation tasks.
• Goal workflow boundary: when a plan compares Claude Code /goal, Ralph, Team, UltraQA, or artifact-only Ultragoal, identify exactly one primary loop authority and use the deterministic conflict policies refuse, adopt_existing, and artifact_only rather than non-deterministic warning handling. /goal facts must cite Claude Code/Anthropic sources only (Claude Code /goal docs: https://code.claude.com/docs/en/goal; Anthropic Claude Code changelog: https://raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.md), and plans MUST NOT claim the /goal evaluator independently runs commands or reads files; require surfaced proof evidence before any completion claim.
• Goal workflow doc target: for user-facing comparisons, keep examples aligned with docs/shared/mode-selection-guide.md#goal-oriented-workflow-selection and docs/REFERENCE.md#goal-workflow-ux-goal-ralph-team-ultraqa-ultragoal. </Execution_Policy>

<Steps>

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); add --interactive for user prompts at draft and approval steps
Review	--review, "review this plan"	Critic evaluation of existing plan

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

RALPLAN-DR modes: Short (default, bounded structure) and Deliberate (for --deliberate or explicit high-risk requests). Both modes keep the same Planner -> Architect -> Critic sequence and the same AskUserQuestion gates.

Provider overrides (supported when the provider CLI is installed):

• --architect codex — replace the Claude Architect pass with omc ask codex --agent-prompt architect "..." for implementation-heavy architecture review
• --critic codex — replace the Claude Critic pass with omc ask codex --agent-prompt critic "..." for an external review pass before execution
• If the requested provider is unavailable, briefly note that and continue with the default Claude Architect/Critic step for that stage

State lifecycle: The persistent-mode stop hook uses ralplan-state.json to enforce continuation during the consensus loop. The skill MUST manage this state:

• On entry: Call state_write(mode="ralplan", active=true, session_id=<current_session_id>) before step 1
• On handoff to execution (approval → ralph/team): Call state_write(mode="ralplan", active=false, session_id=<current_session_id>). Do NOT use state_clear here — state_clear writes a 30-second cancel signal that disables stop-hook enforcement for ALL modes, leaving the newly launched execution mode unprotected.
• On true terminal exit (rejection, non-interactive plan output, error/abort): Call state_clear(mode="ralplan", session_id=<current_session_id>) — no execution mode follows, so the cancel signal window is harmless.
• Do NOT clear during intermediate steps like Critic approval or max-iteration presentation, as the user may still select "Request changes".

Without cleanup, the stop hook blocks all subsequent stops with [RALPLAN - CONSENSUS PLANNING] reinforcement messages even after the consensus workflow has finished. Always pass session_id to avoid clearing other concurrent sessions' state.

1. Planner creates initial plan and a compact RALPLAN-DR summary before any Architect review. The summary MUST include:
   • Principles (3-5)
   • Decision Drivers (top 3)
   • Viable Options (>=2) with bounded pros/cons for each option
   • If only one viable option remains, an explicit invalidation rationale for the alternatives that were rejected
   • In deliberate mode: a pre-mortem (3 failure scenarios) and an expanded test plan covering unit / integration / e2e / observability
2. User feedback (--interactive only): If running with --interactive, MUST use AskUserQuestion to present the draft plan plus the RALPLAN-DR Principles / Decision Drivers / Options summary for early direction alignment with these options:
   • Proceed to review — send to Architect and Critic for evaluation
   • Request changes — return to step 1 with user feedback incorporated
   • Skip review — go directly to final approval (step 7) If NOT running with --interactive, automatically proceed to review (step 3).
3. Architect reviews for architectural soundness using Task(subagent_type="oh-my-claudecode:architect", ...). Architect review MUST include: strongest steelman counterargument (antithesis) against the favored option, at least one meaningful tradeoff tension, and (when possible) a synthesis path. In deliberate mode, Architect should explicitly flag principle violations. Wait for this step to complete before proceeding to step 4. Do NOT run steps 3 and 4 in parallel. Architect MUST evaluate the same fixed plan snapshot produced by Planner in step 1 without mutating it; Architect output MUST NOT be passed to Critic.
4. Critic evaluates against quality criteria using Task(subagent_type="oh-my-claudecode:critic", ...). Critic MUST

---

Content truncated.