omc-plan

<用途> Plan 通过智能交互制定全面、可执行的工作计划。它会自动判断是采用访谈模式（针对广泛请求）还是直接规划模式（针对详细请求），并支持共识模式（迭代式规划师/架构师/评审师循环与 RALPLAN-DR 结构化讨论）和评审模式（对现有计划进行评审师评估）。 </用途>

<使用时机>

• 用户希望在实施前进行规划——例如“规划这个”、“规划……”、“我们来规划一下”
• 用户需要对模糊的想法进行结构化的需求收集
• 用户希望审查现有计划——例如“审查这个计划”、--review
• 用户希望对计划进行多角度共识评估——--consensus、“ralplan”
• 任务宽泛或模糊，在编写任何代码之前需要界定范围 </使用时机>

<不应使用时机>

• 用户希望自主端到端执行——请使用 autopilot 代替
• 用户希望立即开始编码，且任务清晰——请使用 ralph 或委托给执行者
• 用户询问一个可以直接回答的简单问题——直接回答即可
• 任务是范围明确的单一集中修复——请使用执行技能，不要通过此规划模块运行 </不应使用时机>

<存在理由> 在未理解需求的情况下直接编写代码会导致返工、范围蔓延以及遗漏边缘情况。Plan 提供结构化的需求收集、专家分析和质量把关的计划，使执行能够建立在坚实的基础上。共识模式为高风险项目增加了多角度验证。 </存在理由>

<执行策略>

• 根据请求的具体程度自动检测访谈模式还是直接模式
• 在访谈期间一次只问一个问题——切勿批量提出多个问题
• 在向用户询问之前，通过 explore 代理收集代码库事实
• 计划必须达到质量标准：80% 以上的主张需引用文件/行号，90% 以上的标准需可测试
• 默认情况下，共识模式完全自动化运行；添加 --interactive 可在草稿审查和最终审批步骤中启用用户提示
• 共识模式默认使用 RALPLAN-DR 短模式；当请求明确表示高风险（身份验证/安全、数据迁移、破坏性/不可逆更改、生产事件、合规/PII、公共 API 破坏）时，使用 --deliberate 切换到审慎模式
• 规划/执行边界： 规划模式仅检查上下文并生成计划/规范/提案。除非用户在当前轮次中或通过结构化审批 UI 明确选择执行，否则它们必须将工件标记为“待审批”。在获得明确的执行批准之前，规划模式不得运行变更导向的 shell 命令、编辑源文件、提交、推送、打开 PR、调用执行技能或委派实施任务。
• 目标工作流边界： 当计划比较 Claude Code /goal、Ralph、Team 或仅限工件的 Ultragoal 时，需确定一个主要循环权威，并使用确定性冲突策略 refuse、adopt_existing 和 artifact_only，而不是非确定性警告处理。/goal 的事实必须仅引用 Claude Code/Anthropic 来源（Claude Code /goal 文档：https://code.claude.com/docs/en/goal；Anthropic Claude Code 更新日志：https://raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.md），计划不得声称 /goal 评估器独立运行命令或读取文件；在任何完成声明之前，需要提供浮现的证据。
• 目标工作流文档目标： 对于面向用户的比较，保持示例与 docs/shared/mode-selection-guide.md#goal-oriented-workflow-selection 和 docs/REFERENCE.md#goal-workflow-ux-goal-ralph-team-ultragoal 一致。 </执行策略>

<步骤>

模式选择

模式	触发条件	行为
访谈模式	默认为广泛请求	交互式需求收集
直接模式	--direct 或详细请求	跳过访谈，直接生成计划
共识模式	--consensus, "ralplan"	规划师 -> 架构师 -> 评审师循环，直至达成一致，并采用 RALPLAN-DR 结构化讨论（默认短模式，高风险时使用 --deliberate）；添加 --interactive 可在草稿和审批步骤中启用用户提示
评审模式	--review, "审查这个计划"	对现有计划进行评审师评估

访谈模式（广泛/模糊请求）

1. 分类请求：广泛（模糊动词、未指定具体文件、涉及 3 个以上领域）会触发访谈模式
2. 使用 AskUserQuestion 提出一个重点问题，询问偏好、范围和约束
3. 首先收集代码库事实：在询问“你的代码使用了什么模式？”之前，启动一个 explore 代理来查明，然后提出有根据的后续问题
4. 基于答案构建：每个问题都建立在上一个答案的基础上
5. 咨询分析师（Opus）以发现隐藏需求、边缘情况和风险
6. 当用户表示准备好时创建计划：例如“创建计划”、“我准备好了”、“把它做成工作计划”

直接模式（详细请求）

1. 快速分析：可选地简短咨询分析师
2. 创建计划：立即生成全面的工作计划
3. 审查（可选）：如果请求，则进行评审师审查

共识模式（--consensus / "ralplan"）

RALPLAN-DR 模式：短模式（默认，有界结构）和审慎模式（用于 --deliberate 或明确的高风险请求）。两种模式保持相同的规划师 -> 架构师 -> 评审师序列和相同的 AskUserQuestion 关口。

提供者覆盖（在安装提供者 CLI 时支持）：

• --architect codex — 将 Claude 架构师传递替换为 omc ask codex --agent-prompt architect "..."，用于实现密集的架构审查
• --critic codex — 将 Claude 评审师传递替换为 omc ask codex --agent-prompt critic "..."，用于在执行前进行外部审查
• 如果请求的提供者不可用，简要说明并继续使用该阶段的默认 Claude 架构师/评审师步骤

状态生命周期：持久模式的停止钩子使用 ralplan-state.json 来强制在共识循环期间继续执行。该技能必须管理此状态：

• 进入时：在步骤 1 之前调用 state_write(mode="ralplan", active=true, session_id=<current_session_id>)
• 移交给执行时（批准 -> ralph/team）：调用 state_write(mode="ralplan", active=false, session_id=<current_session_id>)。不要在此处使用 state_clear — state_clear 会写入一个 30 秒的取消信号，这会禁用所有模式的停止钩子强制执行，使新启动的执行模式不受保护。
• 真正终止退出时（拒绝、非交互式计划输出、错误/中止）：调用 state_clear(mode="ralplan", session_id=<current_session_id>) — 后续没有执行模式，因此取消信号窗口是无害的。
• 不要在中间步骤（如评审师批准或最大迭代次数呈现）进行清除，因为用户可能仍会选择“请求更改”。

如果不进行清理，停止钩子会阻止所有后续停止，并显示 [RALPLAN - 共识规划] 强化消息，即使共识工作流已经完成。始终传递 session_id 以避免清除其他并发会话的状态。

1. 规划师在任何架构师审查之前创建初始计划和紧凑的 RALPLAN-DR 摘要。摘要必须包括：

   • 原则（3-5 条）
   • 决策驱动因素（前 3 个）
   • 可行选项（>=2 个），每个选项附带有限的优缺点
   • 如果只剩下一个可行选项，则需要为被拒绝的替代方案提供明确的无效理由
   • 在审慎模式下：一个事前分析（3 个失败场景）和一个涵盖单元 / 集成 / 端到端 / 可观测性的扩展测试计划

2. 用户反馈 （仅 --interactive）：如果使用 --interactive 运行，必须使用 AskUserQuestion 呈现草稿计划以及 RALPLAN-DR 原则 / 决策驱动因素 / 选项摘要，以便早期方向对齐，并提供以下选项：

   • 继续审查 — 发送给架构师和评审师进行评估
   • 请求更改 — 返回步骤 1，融入用户反馈
   • 跳过审查 — 直接进入最终批准（步骤 7） 如果未使用 --interactive 运行，则自动继续审查（步骤 3）。

3. 架构师使用 Task(subagent_type="oh-my-claudecode:architect", ...) 审查架构合理性。架构师审查必须包括：对首选选项的最强稻草人反驳论点（对立论点）、至少一个有意义的权衡张力，以及（如果可能）一个综合路径。在审慎模式下，架构师应明确标记原则违规。等待此步骤完成后才能进入步骤 4。 不要并行运行步骤 3 和 4。架构师必须评估由规划师在步骤 1 中产生的相同固定计划快照，而不得对其进行变异；架构师的输出不得传递给评审师。

4. 评审师使用 Task(subagent_type="oh-my-claudecode:critic", ...) 根据质量标准进行评估。评审师必须验证原则-选项一致性、公平的替代方案探索、风险缓解的清晰性、可测试的验收标准以及具体的验证步骤。评审师必须明确拒绝肤浅的替代方案、驱动因素矛盾、模糊的风险或薄弱的验证。在审慎模式下，评审师必须拒绝缺失/薄弱的事前分析或缺失/薄弱的扩展测试计划。仅在步骤 3 完成后运行。评审师必须独立评估相同的固定计划快照，作为单独的、独立等待的 Task 调用；评审师不得消费或接收架构师的审查。

   对一份固定计划快照进行独立的顺序审查。 架构师和评审师各自审查由规划师在步骤 1 中产生的相同固定计划快照，并且任一审查都不得对其进行变异。架构师的输出不得传递给评审师。架构师和评审师必须作为单独的、独立等待的 Task 调用顺序运行——绝不能并行——并且直到架构师 Task 完成并等待其结果后，才能发出评审师 Task。评审师不得消费或接收架构师的审查。架构师和评审师的结果只能由规划师在修订或改进综合期间合并，并且只有在两次审查都完成后才能进行。

5. 重新审查循环（最多 5 次迭代）：如果评审师拒绝，则执行此封闭循环： a. 收集架构师 + 评审师的所有拒绝反馈（仅限规划师综合：架构师和评审师结果只能由规划师合并，且只有在两次审查都完成后） b. 将反馈传递给规划师以生成修订计划 c. 返回步骤 3 — 架构师审查修订计划 d. 返回步骤 4 — 评审师评估修订计划 e. 重复直到评审师批准或达到最大 5 次迭代 f. 如果达到最大迭代次数仍未批准，则通过 AskUserQuestion 向用户呈现最佳版本，并注明未达成专家共识

6. 应用改进：当评审者批准但带有改进建议时，在继续之前将所有接受的改进合并到计划文件中。最终共识输出必须包含一个 ADR 部分，其中包括：决策、驱动因素、考虑的替代方案、选择原因、后果、后续事项。具体来说： a. 收集架构师和评审师响应中的所有改进建议 b. 去重并分类建议 c. 使用接受的改进更新 .omc/plans/ 中的计划文件（添加缺失的细节、细化步骤、加强验收标准、更新 ADR 等） d. 在计划末尾的简短变更日志部分注明应用了哪些改进

7. 在评审师批准（已应用改进）后：将计划状态标记为“待审批”，除非已经捕获了明确的执行批准。 （仅 --interactive） 如果使用 --interactive 运行，使用 AskUserQuestion 呈现计划，并提供以下选项：

   • 批准通过 team 执行（推荐） — 明确选择通过协调的并行团队代理 (/team) 继续进行。Team 自 v4.1.7 起是规范的编排界面。
   • 批准通过 ralph 执行 — 明确选择通过 Ralph 持久化并带验证继续进行
   • 压缩后返回执行批准 — 明确选择先压缩上下文窗口（规划后上下文较大时推荐），然后停止在保存的待审批计划处，并在启动执行前再次询问
   • 请求更改 — 返回步骤 1，融入用户反馈
   • 拒绝 — 完全放弃计划 如果未使用 --interactive 运行，输出标记为“待审批”的最终计划，调用 state_clear(mode="ralplan", session_id=<current_session_id>)，然后停止。请勿自动执行。

8. （仅 --interactive） 用户通过结构化的 AskUserQuestion UI 进行选择（切勿以纯文本形式请求批准）。如果用户选择拒绝，调用 state_clear(mode="ralplan", session_id=<current_session_id>) 并停止。

9. 关于用户

…

[已截断以供翻译]