Plan

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 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, cite $best-practice-research evidence and synthesize it into the plan instead of recommending Autoresearch as a final architecture component. For durable-goal work that is also parallelizable, explicitly recommend Team + Ultragoal: Ultragoal remains leader-owned goal/ledger state and Team returns checkpoint-ready execution evidence. g. For the $team path, add an explicit launch-hint block with concrete omx team / $team commands and a team verification path (what Team proves before shutdown and what Ultragoal checkpoints as durable completion evidence). Distinguish Team + Ultragoal from any explicit Ralph fallback: Team handles coordinated parallel lanes; Ultragoal is the default durable follow-up/ledger owner, and Ralph is only an explicitly requested legacy-style persistent sequential verification/fix lane when needed.
7. On Critic approval (with improvements applied): (--interactive only) If running with --interactive, use AskUserQuestion / the structured question UI to present the plan with these options:
   • Approve durable goal execution — proceed via $ultragoal by default (optionally with $team for parallel lanes)
   • Approve and implement via team — proceed to implementation via coordinated parallel team agents
   • Start goal-mode follow-up — proceed via $ultragoal by default, or $autoresearch-goal / $performance-goal when the approved plan specifically fits research validation or measurable optimization
   • Request changes — return to step 1 with user feedback
   • Reject — discard the plan entirely If NOT running with --interactive, output the final approved plan and stop. Do NOT auto-execute.
8. (--interactive only) User chooses via the structured question UI (never ask for approval in plain text when a structured surface is available)
9. On user approval (--interactive only):
   • Approve durable goal execution: MUST invoke $ultragoal with the approved plan path from .omx/plans/ as context plus the explicit available-agent-types roster, suggested reasoning levels, concrete role allocation guidance, and direct launch hints for Ultragoal follow-up work. Use $team alongside Ultragoal when parallel lanes are warranted. Do NOT implement directly. Do NOT edit source code files in the planning agent. Ralph is not the default follow-up; only invoke $ralph when the user explicitly selects a legacy/persistent single-owner execution lane.
   • Approve and implement via team: MUST invoke $team with the approved plan path from .omx/plans/ as context plus the explicit available-agent-types roster, suggested reasoning levels, concrete staffing / worker-role allocation guidance, explicit omx team / $team launch hints, and the team verification path. Do NOT implement directly. The team skill coordinates parallel agents across the staged pipeline for faster execution on large tasks.
   • Start goal-mode follow-up: MUST invoke the selected goal workflow with the approved plan path and appropriate success context: $ultragoal as the default goal-mode path, $autoresearch-goal for research projects, or $performance-goal for optimization/performance projects with measurable evaluator criteria. Do NOT implement directly in the planning agent.

Review Mode (--review)

0. Treat review as a reviewer-only pass. The context that wrote the plan, cleanup proposal, or diff MUST NOT be the context that approves it.
1. Read plan file from .omx/plans/
2. Evaluate via Critic using ask_codex with agent_role: "critic"
3. For cleanup/refactor/anti-slop work, verify that the artifact includes a cleanup plan, regression tests or an explicit test gap, smell-by-smell passes, and quality gates.
4. Return verdict: APPROVED, REVISE (with specific feedback), or REJECT (replanning required)
5. If the current context authored the artifact, hand the review to $code-review, critic, quality-reviewer, or verifier as appropriate.

Plan Output Format

Every plan includes:

• Requirements Summary
• Acceptance Criteria (testable)
• Implementation Steps (with file references)
• Adaptive step count sized to the actual scope (not a fixed five-step template)
• Risks and Mitigations
• Verification Steps
• For consensus/ralplan: RALPLAN-DR summary (Principles, Decision Drivers, Options)
• For consensus/ralplan final output: ADR (Decision, Drivers, Alternatives considered, Why chosen, Consequences, Follow-ups)
• For consensus/ralplan execution handoff: Available-Agent-Types Roster, Follow-up Staffing Guidance (including suggested reasoning levels by lane), product-facing Goal-Mode Follow-up Suggestions ($ultragoal, $autoresearch-goal, $performance-goal when contextually appropriate), explicit omx team / $team Launch Hints, and Team Verification Path
• For deliberate consensus mode: Pre-mortem (3 scenarios) and Expanded Test Plan (unit/integration/e2e/observability)

Plans are saved to .omx/plans/. Drafts go to .omx/drafts/.

Scenario Examples

Good: The user says continue after the workflow already has a clear next step. Continue the current branch of work instead of restarting or re-asking the same question.

Good: The user changes only the output shape or downstream delivery step (for example make a PR). Preserve earlier non-conflicting workflow constraints and apply the update locally.

Bad: The user says continue, and the workflow restarts discovery or stops before the missing verification/evidence is gathered.

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.