ralplan

Ralplan (Consensus Planning Alias)

Ralplan is a shorthand alias for $plan --consensus. It triggers iterative planning with Planner, Architect, and Critic agents until consensus is reached, with RALPLAN-DR structured deliberation (short mode by default, deliberate mode for high-risk work).

Usage

$ralplan "task description"

Flags

• --interactive: Enables user prompts at key decision points (draft review in step 2 and final approval in step 6). Without this flag the workflow runs fully automated — Planner → Architect → Critic loop — and outputs the final plan without asking for confirmation.
• --deliberate: Forces deliberate mode for high-risk work. Adds pre-mortem (3 scenarios) and expanded test planning (unit/integration/e2e/observability). Without this flag, deliberate mode can still auto-enable when the request explicitly signals high risk (auth/security, migrations, destructive changes, production incidents, compliance/PII, public API breakage).

Usage with interactive mode

$ralplan --interactive "task description"

Behavior

GPT-5.5 Guidance Alignment

Use 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, right-sized implementation/PRD shape, and automatic continuation for safe reversible steps. Ask only for material, destructive, credentialed, external-production, or preference-dependent branches.

This skill invokes the Plan skill in consensus mode:

$plan --consensus <arguments>
$plan --consensus --interactive <arguments>

The consensus workflow:

1. Planner creates an adaptive plan (right-sized to task scope; do not default to exactly five steps) and a compact RALPLAN-DR summary before review:
   • Principles (3-5)
   • Decision Drivers (top 3)
   • Viable Options (>=2) with bounded pros/cons
   • If only one viable option remains, explicit invalidation rationale for alternatives
   • Deliberate mode only: pre-mortem (3 scenarios) + expanded test plan (unit/integration/e2e/observability)
2. User feedback (--interactive only): If --interactive is set, use the structured question UI (omx question in attached tmux; native structured input outside tmux when available) to present the draft plan plus the Principles / Drivers / Options summary before review (Proceed to review / Request changes / Skip review). Otherwise, automatically proceed to review.
3. Architect reviews for architectural soundness and must provide the strongest steelman antithesis, at least one real tradeoff tension, and (when possible) synthesis — await completion before step 4. In deliberate mode, Architect should explicitly flag principle violations.
4. Critic evaluates against quality criteria — run only after step 3 completes. Critic must enforce principle-option consistency, fair alternatives, risk mitigation clarity, testable acceptance criteria, and concrete verification steps. In deliberate mode, Critic must reject missing/weak pre-mortem or expanded test plan.
5. Re-review loop (max 5 iterations): Any non-APPROVE Critic verdict (ITERATE or REJECT) MUST run the same full closed loop: a. Collect Architect + Critic feedback b. Revise the plan with Planner c. Return to Architect review d. Return to Critic evaluation e. Repeat this loop until Critic returns APPROVE or 5 iterations are reached f. If 5 iterations are reached without APPROVE, present the best version to the user
6. On Critic approval (--interactive only): If --interactive is set, use the structured question UI to present the plan with approval options (Approve and execute via ralph / Approve and implement via team / Start a goal-mode follow-up / Request changes / Reject). Final plan must include ADR (Decision, Drivers, Alternatives considered, Why chosen, Consequences, Follow-ups), an explicit available-agent-types roster, concrete follow-up staffing guidance for both ralph and team, suggested reasoning levels by lane, explicit omx team / $team launch hints, a concrete team verification path, and a product-facing Goal-Mode Follow-up Suggestions section. Recommend $ultragoal by default for goal-mode follow-up, use $autoresearch-goal instead when the context is a research project, and use $performance-goal instead when the context is an optimization or performance project. Otherwise, output the final plan and stop.
7. (--interactive only) User chooses: Approve (ralph, team, or a goal-mode follow-up), Request changes, or Reject
8. (--interactive only) On approval: invoke $ralph for sequential execution, $team for parallel team execution, or the selected goal-mode follow-up ($ultragoal, $autoresearch-goal, or $performance-goal) with the approved plan and matching success/evaluator context -- never implement directly. Preserve the explicit available-agent-types roster, reasoning-by-lane guidance, role/staffing allocation guidance, launch hints, and verification-path guidance from the approved plan for Ralph/team paths.

Important: Steps 3 and 4 MUST run sequentially. Do NOT issue both agent calls in the same parallel batch. Always await the Architect result before invoking Critic.

Follow the Plan skill's full documentation for consensus mode details.

Goal-Mode Follow-up Suggestions

When ralplan outputs a final handoff or asks the user to choose a next lane, include product-facing goal-mode suggestions alongside the existing Ralph and team options:

• $ultragoal — default goal-mode follow-up for implementation or general goal-oriented follow-up plans that should become durable Codex/OMX goals with sequential completion tracking.
• $autoresearch-goal — research-project follow-up when the plan centers on a question, literature/reference gathering, evaluator-backed research, or a professor/critic-style research deliverable.
• $performance-goal — optimization/performance follow-up when the plan centers on speed, latency, throughput, memory, benchmark, or other measurable performance work.

Keep $ralph and $team as first-class execution options where appropriate: use Ralph for persistent single-owner completion/verification pressure and team for coordinated parallel implementation. Do not present the goal-mode options as replacements for Ralph/team when the task is mainly implementation delivery; present them as better fits when durable goal tracking, research validation, or performance evaluators are the primary need.

Pre-context Intake

Before consensus planning or execution handoff, ensure a grounded context snapshot exists:

1. Derive a task slug from the request.
2. Reuse the latest relevant snapshot in .omx/context/{slug}-*.md when available.
3. If none exists, create .omx/context/{slug}-{timestamp}.md (UTC YYYYMMDDTHHMMSSZ) with:
   • task statement
   • desired outcome
   • known facts/evidence
   • constraints
   • unknowns/open questions
   • likely codebase touchpoints
4. If ambiguity remains high, gather brownfield facts first. When session guidance enables USE_OMX_EXPLORE_CMD, prefer omx explore for simple read-only repository lookups with narrow, concrete prompts; otherwise use the richer normal explore path. Then run $deep-interview --quick <task> before continuing.
5. If the plan depends on official docs, version-aware framework guidance, best practices, or external dependency behavior, auto-delegate researcher before finalizing the planning handoff so execution does not start from repo-local recall alone.

Do not hand off to execution modes until this intake is complete; if urgency forces progress, explicitly document the risk tradeoffs.

Pre-Execution Gate

Why the Gate Exists

Execution modes (ralph, autopilot, team, ultrawork) spin up heavy multi-agent orchestration. When launched on a vague request like "ralph improve the app", agents have no clear target — they waste cycles on scope discovery that should happen during planning, often delivering partial or misaligned work that requires rework.

The ralplan-first gate intercepts underspecified execution requests and redirects them through the ralplan consensus planning workflow. This ensures:

• Explicit scope: A PRD defines exactly what will be built
• Test specification: Acceptance criteria are testable before code is written
• Consensus: Planner, Architect, and Critic agree on the approach
• No wasted execution: Agents start with a clear, bounded task

Good vs Bad Prompts

Passes the gate (specific enough for direct execution):

• ralph fix the null check in src/hooks/bridge.ts:326
• autopilot implement issue #42
• team add validation to function processKeywordDetector
• ralph do:\n1. Add input validation\n2. Write tests\n3. Update README
• ultrawork add the user model in src/models/user.ts

Gated — redirected to ralplan (needs scoping first):

• ralph fix this
• autopilot build the app
• team improve performance
• ralph add authentication
• ultrawork make it better

Bypass the gate (when you know what you want):

• force: ralph refactor the auth module
• ! autopilot optimize everything

When the Gate Does NOT Trigger

The gate auto-passes when it detects any concrete signal. You do not need all of them — one is enough:

Signal Type	Example prompt	Why it passes
File path	ralph fix src/hooks/bridge.ts	References a specific file
Issue/PR number	ralph implement #42	Has a concrete work item
camelCase symbol	ralph fix processKeywordDetector	Names a specific function
PascalCase symbol	ralph update UserModel	Names a specific class
snake_case symbol	team fix user_model	Names a specific identifier
Test runner	ralph npm test && fix failures	Has an explicit test target
Numbered steps	`ral

---

Content truncated.