| name | ralplan |
| description | Use as an explicit compatibility alias for consensus-oriented planning when the user wants a higher-trust plan before execution. |
| argument-hint | [task, approved design, or consensus planning request] |
Agmo Ralplan
Treat this as a compatibility alias of plan, not as a separate canonical workflow stage.
Main behavior
- route to the
plan workflow semantics
- raise the planning bar by making assumptions, non-goals, risks, and verification path explicit
- use
agmo-explore for repo facts before debating internals the codebase can answer
- pull in
agmo-architect for boundary and tradeoff review
- pull in
agmo-critic when the plan needs a stronger challenge pass before execution
- end with an execution-ready handoff, usually into
plan-review or execute
Native subagent lifecycle
When spawning native subagents for this workflow, keep each agent id until its result is integrated, then call close_agent for completed, failed, superseded, or no-longer-needed lanes so thread slots are released before the next delegation.
Expected output shape
A strong ralplan result should usually include:
- a concise requirements summary
- decision drivers or main planning principles
- viable options or the invalidation reason for discarded options
- recommended direction
- testable acceptance criteria
- risks, mitigations, and verification path
Artifact save body
Before ending a meaningful consensus-planning stage, make the final response or delegated result save-ready:
- goal, principles, and decision drivers
- options and chosen direction
- acceptance criteria
- verification path
- risks and execution handoff
Hard gate
ralplan should not auto-start implementation. It is still a planning-lane workflow.
Canonical name
Use plan in docs, onboarding, and workflow descriptions. Keep ralplan available so users can explicitly ask for a consensus-style planning pass without introducing a separate workflow stage.
