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 -- 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
• omx explore is deprecated. Use normal repository inspection tools/subagents for simple read-only repository lookups during planning; use omx sparkshell only for explicit shell-native read-only evidence, and keep prompt-heavy or ambiguous planning work on the richer normal path.
• 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>

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

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 the surface-appropriate structured question path for preferences, scope, and constraints: in attached-tmux OMX runtime use omx question; outside tmux use native structured input when available; use plain text only as a last fallback
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 (THOROUGH tier) 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. The workflow auto-proceeds through planning steps (Planner/Architect/Critic) but outputs the final plan without executing.

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 / the structured question UI (omx question in attached tmux; native structured input outside tmux when available) 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 as a dedicated subsequent Architect subagent with the full task, current plan text/path, RALPLAN-DR summary, and relevant artifact context. 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. Do NOT substitute a default/improvised subagent prompt for the role-specific Architect prompt.
4. Critic evaluates against quality criteria as a dedicated subsequent Critic subagent with the full task, current plan text/path, RALPLAN-DR summary, artifact context, and the completed Architect result. Critic MUST verify principle-option consistency, fair alternative exploration, risk mitigation clarity, testable acceptance criteria, and concrete verification steps. Critic MUST explicitly reject shallow alternatives, driver contradictions, vague risks, or weak verification. In deliberate mode, Critic MUST reject missing/weak pre-mortem or missing/weak expanded test plan. Run only after step 3 is complete. Do NOT let the Architect response self-approve the Critic gate.
5. Re-review loop (max 5 iterations): If Critic rejects or iterates, execute this closed loop: a. Collect all feedback from Architect + Critic b. Pass feedback to Planner to produce a revised plan c. Return to Step 3 — Architect reviews the revised plan d. Return to Step 4 — Critic evaluates the revised plan e. Repeat until Critic approves OR max 5 iterations reached f. If max iterations reached without approval, present the best version to user via the structured question UI with note that expert consensus was not reached
6. Apply improvements: When reviewers approve with improvement suggestions, merge all accepted improvements into the plan file before proceeding. Final consensus output MUST include an ADR section with: Decision, Drivers, Alternatives considered, Why chosen, Consequences, Follow-ups. Specifically: a. Collect all improvement suggestions from Architect and Critic responses b. Deduplicate and categorize the suggestions c. Update the plan file in .omx/plans/ with the accepted improvements (add missing details, refine steps, strengthen acceptance criteria, ADR updates, etc.) d. Note which improvements were applied in a brief changelog section at the end of the plan e. Before any execution handoff, derive an explicit available-agent-types roster from the known prompt catalog and add concrete follow-up staffing guidance for $ultragoal and $team (recommended roles, counts, suggested reasoning levels by lane, and why each lane exists), plus an explicit $ralph fallback note only when persistent single-owner verification is intentionally selected f. Add a product-facing Goal-Mode Follow-up Suggestions section: recommend $ultragoal by default for general goal-oriented follow-up, $autoresearch-goal only when the context is a research project with a research deliverable/evaluator, and $performance-goal when the context is an optimization or performance project. Keep these suggestions alongside the Team path and any explicit Ralph fallback rather than replacing implementation-delivery guidance. For ordinary pre-planning external docs or best-practice lookup, c

---

Content truncated.