用途：在实现涉及多个文件或组件、或架构决策需要多视角验证时，先产出经压力测试的共识实现计划；用户说“plan this”“consensus plan”“ralplan”等时使用。单文件小改动、方案显而易见且低风险、或用户明确跳过规划时不适用。前置条件：目标清晰（含糊先用 omh-deep-interview），且可用 delegate_task 工具。
流程：阶段 0 收集上下文，读取相关文件、识别既有模式与约束，汇总约 500 字上下文供所有子代理使用。阶段 1 规划循环（最多 3 轮）：第 1 轮顺序执行 Planner→Architect→Critic，各一次 delegate_task，目标中以 [omh-role:planner] 等标记角色，并在 goal 中写全规格，子代理初始无上下文；随后做共识检查，三者全部 APPROVE 即通过，任一 REQUEST_CHANGES 收集反馈进入第 2 轮，任一 REJECT 则输出顾虑并询问用户是否继续。第 2 轮起 Planner 修订并收到全部反馈（含 A1、C1、W1 等编号），Architect 与 Critic 相互独立，用批量 delegate_task 并行复审。阶段 2 输出共识计划到 .omh/plans/ralplan-{slug}.md，含共识状态、修订摘要、最终计划（任务、依赖、复杂度、验收标准）、风险与未决问题，并向用户给出关键设计决策摘要。slug 用描述性名称而非时间戳。
状态管理：状态按 slug 为实例键（instance_id），不同目标的会话可并发；有 omh 插件时用 omh_state 读写，无插件则手写 .omh/state/ralplan--{slug}.json；中断后可列出活动实例并从最后完成阶段恢复；省略 instance_id 的旧式单例回退仅在单实例时可用。用户要求 deliberate 模式或提到 ADR、decision record 时，架构师输出采用 ADR 格式，模板见 references/adr-template.md。
注意事项：角色标记必须写入 goal，不要手写角色提示词；goal 与 context 须自包含；第 2 轮起并行复审；反馈编号便于逐项核对；循环不超过 3 轮，第 3 轮仍无共识则带说明输出；每个子代理都需项目上下文；批评者应质疑而非阻断，问题轻微可保留意见通过；目标含糊则建议改用 omh-deep-interview；用 todo 跟踪轮次与阶段；从参考系统移植时须让三个角色读取真实源码而非摘要。收费、价格与平台等信息暂未提供。