ralplan

Ralplan (Consensus Planning Alias)

Ralplan is a shorthand alias for /omp: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

/omp: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

/omp:ralplan --interactive "task description"

Behavior

This skill invokes the Plan skill in consensus mode:

/omp:plan --consensus <arguments>

The consensus workflow:

1. Planner creates initial plan 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 AskUserQuestion 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.

   Adopt the Architect role: "Review this plan for architectural soundness. Provide the strongest steelman antithesis against the favored option, at least one real tradeoff tension, and a synthesis path where possible."

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.

   Adopt the Critic role: "Evaluate this plan. Verify principle-option consistency, fair alternative exploration, risk mitigation clarity, testable acceptance criteria, and concrete verification steps. Explicitly reject shallow alternatives, driver contradictions, vague risks, or weak verification."

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 AskUserQuestion to present the plan with approval options:

   • Approve and implement via team (Recommended) — proceed via omp:team
   • Approve and execute via ralph — proceed via omp:ralph
   • Clear context and implement — compact context first, then omp:ralph with the saved plan file
   • Request changes — return to step 1
   • Reject — discard the plan entirely Final plan must include ADR (Decision, Drivers, Alternatives considered, Why chosen, Consequences, Follow-ups). Otherwise (non-interactive), output the final plan and stop.

7. (--interactive only) User chooses: Approve (team or ralph), Request changes, or Reject

8. (--interactive only) On approval: invoke omp:team for parallel team execution (recommended) or omp:ralph for sequential execution — never implement directly

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

Follow the omp-plan skill's full documentation for consensus mode details.

---

Pre-Execution Gate

Why the Gate Exists

Execution modes (omp:ralph, omp:autopilot, omp:team, omp: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	ralph do:\n1. Add X\n2. Test Y	Structured deliverables
Acceptance criteria	ralph add login - acceptance criteria: ...	Explicit success definition
Error reference	ralph fix TypeError in auth	Specific error to address
Code block	ralph add: \``ts ... ````	Concrete code provided
Escape prefix	force: ralph do it or ! ralph do it	Explicit user override

End-to-End Flow Example

1. User types: ralph add user authentication
2. Gate detects: execution keyword (ralph) + underspecified prompt (no files, functions, or test spec)
3. Gate redirects to ralplan with message explaining the redirect
4. Ralplan consensus runs:
   • Planner creates initial plan (which files, what auth method, what tests)
   • Architect reviews for soundness
   • Critic validates quality and testability
5. On consensus approval, user chooses execution path:
   • omp:team: parallel coordinated agents (recommended)
   • omp:ralph: sequential execution with verification
6. Execution begins with a clear, bounded plan

Troubleshooting

Issue	Solution
Gate fires on a well-specified prompt	Add a file reference, function name, or issue number to anchor the request
Want to bypass the gate	Prefix with force: or ! (e.g., force: ralph fix it)
Gate does not fire on a vague prompt	The gate only catches prompts with <=15 effective words and no concrete anchors; add more detail or use /omp:ralplan explicitly
Redirected to ralplan but want to skip planning	In the ralplan workflow, say "just do it" or "skip planning" to transition directly to execution