plan

Plan 通过智能交互创建全面、可执行的工作计划。它会自动检测是访谈用户（宽泛请求）还是直接规划（详细请求），并支持共识模式（迭代式 Planner/Architect/Critic 循环，配合 RALPLAN-DR 结构化审议）和审查模式（Critic 对现有计划进行评估）。

<Use_When>

• 用户希望在实施前先规划 -- “plan this”、“plan the”、“let's plan”
• 用户希望为模糊的想法进行结构化需求收集
• 用户希望审查现有计划 -- “review this plan”、--review
• 用户希望就计划达成多视角共识 -- --consensus、“ralplan”
• 任务宽泛或模糊，需要在编写任何代码前明确范围 </Use_When>

<Do_Not_Use_When>

• 用户希望自主端到端执行 -- 改用 autopilot
• 用户希望在有明确任务的情况下立即开始编码 -- 使用 ralph 或委托给 executor
• 用户提出一个可直接回答的简单问题 -- 直接回答即可
• 任务是范围明确的单一聚焦修复 -- 跳过规划，直接执行 </Do_Not_Use_When>

<Why_This_Exists> 在不理解需求的情况下贸然进入编码会导致返工、范围蔓延和遗漏边缘情况。Plan 提供结构化需求收集、专家分析和质量门禁计划，使执行从坚实的基础开始。共识模式为高风险项目增加多视角验证。 </Why_This_Exists>

<Execution_Policy>

• 根据请求的具体程度自动检测访谈模式还是直接模式
• 访谈期间一次只问一个问题 -- 绝不批量提出多个问题
• 在向用户询问之前，先通过 explore Agent 收集代码库事实
• 计划必须达到质量标准：80% 以上的论断引用文件/行，90% 以上的标准可测试
• 共识模式默认完全自动化运行；添加 --interactive 可在草案审查和最终批准步骤启用用户提示
• 共识模式默认使用 RALPLAN-DR 短模式；在 --deliberate 或请求明确表示高风险（认证/安全、数据迁移、破坏性/不可逆变更、生产事故、合规/PII、公共 API 破坏）时切换到审议模式 </Execution_Policy>

模式选择

模式	触发条件	行为
Interview	宽泛请求的默认模式	交互式需求收集
Direct	--direct，或详细请求	跳过访谈，直接生成计划
Consensus	--consensus、“ralplan”	Planner -> Architect -> Critic 循环，直到达成一致，并配合 RALPLAN-DR 结构化审议（默认短模式，高风险时使用 --deliberate）；添加 --interactive 可在草案和批准步骤启用用户提示
Review	--review、“review this plan”	Critic 对现有计划进行评估

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

1. 对请求进行分类：宽泛（模糊动词、没有具体文件、涉及 3 个以上领域）触发访谈模式
2. 提出一个聚焦问题，使用 AskUserQuestion 了解偏好、范围和约束
3. 先收集代码库事实：在询问“你的代码使用什么模式？”之前，先启动一个 explore Agent 查清楚，然后提出有依据的后续问题
4. 基于答案继续构建：每个问题都建立在前一个答案之上
5. 咨询 Analyst（Opus），了解隐藏需求、边缘情况和风险
6. 创建计划：当用户表示准备好时：“create the plan”、“I'm ready”、“make it a work plan”

直接模式（详细请求）

1. 快速分析：可选的简短 Analyst 咨询
2. 创建计划：立即生成全面工作计划
3. 审查（可选）：如有要求，进行 Critic 审查

共识模式（--consensus / “ralplan”）

RALPLAN-DR 模式：Short（默认，结构受限）和 Deliberate（用于 --deliberate 或明确的高风险请求）。两种模式都保持相同的 Planner -> Architect -> Critic 顺序和相同的 AskUserQuestion 门控。

1. Planner 在任何 Architect 审查之前创建初始计划和一份精简的 RALPLAN-DR 摘要。该摘要 必须 包含：
   • 原则（3-5 条）
   • 决策驱动因素（前 3 项）
   • 可行选项（>=2 个），并为每个选项给出有边界的优缺点
   • 如果只剩一个可行选项，则需为被拒绝的替代方案提供明确的 失效理由
   • 在 审慎模式 下：一份 事前验尸（3 个失败场景）和一份 扩展测试计划，覆盖 单元 / 集成 / e2e / 可观测性
2. 用户反馈 (--interactive only)：如果以 --interactive 运行，必须 使用 AskUserQuestion 展示计划草案 以及 RALPLAN-DR 原则 / 决策驱动因素 / 选项摘要，以便尽早对齐方向，并提供以下选项：
   • 进入审查 — 发送给 Architect 和 Critic 进行评估
   • 请求修改 — 返回步骤 1，并纳入用户反馈
   • 跳过审查 — 直接进入最终批准（步骤 7） 如果未以 --interactive 运行，则自动进入审查（步骤 3）。
3. Architect 使用 Task(subagent_type="oh-my-claudecode:architect", ...) 审查架构合理性。Architect 审查 必须 包含：针对首选选项的最强 steelman 反论点（antithesis）、至少一个有意义的价值权衡矛盾，以及（在可能时）一条综合路径。在审慎模式下，Architect 应明确标记原则违背之处。在进入步骤 4 之前，等待此步骤完成。 不要并行运行步骤 3 和步骤 4。
4. Critic 使用 Task(subagent_type="oh-my-claudecode:critic", ...) 依据质量标准进行评估。Critic 必须 验证原则与选项的一致性、对替代方案的公平探索、风险缓解的清晰性、可测试的验收标准，以及具体的验证步骤。Critic 必须 明确拒绝浅薄的替代方案、驱动因素矛盾、模糊的风险或薄弱的验证。在审慎模式下，Critic 必须 拒绝缺失或薄弱的事前验尸，或缺失或薄弱的扩展测试计划。仅在步骤 3 完成后运行。
5. 复审循环（最多 5 次迭代）：如果 Critic 拒绝，则执行此闭环： a. 收集来自 Architect + Critic 的所有拒绝反馈 b. 将反馈传递给 Planner 以生成修订计划 c. 返回步骤 3 — Architect 审查修订计划 d. 返回步骤 4 — Critic 评估修订计划 e. 重复，直到 Critic 批准或达到最多 5 次迭代 f. 如果达到最大迭代次数仍未获批准，则通过 AskUserQuestion 向用户展示最佳版本，并注明未达成专家共识
6. 应用改进：当审查者批准并附有改进建议时，在继续之前将所有已接受的改进合并到计划文件中。最终共识输出 必须 包含一个 ADR 部分，其中包括：决策、驱动因素、考虑过的替代方案、为何选择、后果、后续事项。具体来说： a. 收集来自 Architect 和 Critic 回复的所有改进建议 b. 对建议去重并分类 c. 使用已接受的改进更新 .omc/plans/ 中的计划文件（添加缺失细节、细化步骤、强化验收标准、更新 ADR 等） d. 在计划末尾用一个简短的变更日志部分注明应用了哪些改进
7. 在 Critic 批准后（且已应用改进）：(--interactive only) 如果以 --interactive 运行，使用 AskUserQuestion 展示计划，并提供以下选项：
   • 批准并执行 — 通过 ralph+ultrawork 进入实现
   • 批准并通过团队实现 — 通过协调的并行团队 Agent 进入实现
   • 清理上下文并实现 — 先压缩上下文窗口（当规划后上下文很大时推荐），然后使用已保存的计划文件通过 ralph 开始全新实现
   • 请求修改 — 返回步骤 1，并纳入用户反馈
   • 拒绝 — 完全丢弃该计划 如果未以 --interactive 运行，则输出最终批准的计划并停止。不要自动执行。
8. (--interactive only) 用户通过结构化的 AskUserQuestion UI 进行选择（绝不要以纯文本请求批准）
9. 在用户批准后（仅 --interactive）：
   • 批准并执行：必须 调用 Skill("oh-my-claudecode:ralph")，并将来自 .omc/plans/ 的已批准计划路径作为上下文。不要直接实现。不要在规划 Agent 中编辑源代码文件。ralph 技能通过 ultrawork 并行 Agent 处理执行。
   • 批准并通过团队实现：必须 调用 Skill("oh-my-claudecode:team")，并将来自 .omc/plans/ 的已批准计划路径作为上下文。不要直接实现。team 技能会协调跨分阶段流水线的并行 Agent，以加快大型任务的执行。
   • 清理上下文并实现：首先调用 Skill("compact") 压缩上下文窗口（减少规划期间累积的 token 使用量），然后调用 Skill("oh-my-claudecode:ralph")，并使用来自 .omc/plans/ 的已批准计划路径。当规划会话后上下文窗口已占用 50%+ 时，推荐此路径。

审查模式（--review）

1. 从 .omc/plans/ 读取计划文件
2. 通过 Critic 使用 Task(subagent_type="oh-my-claudecode:critic", ...) 进行评估
3. 返回裁决：APPROVED、REVISE（附具体反馈）或 REJECT（需要重新规划）

计划输出格式

每份计划都包含：

• 需求摘要
• 验收标准（可测试）
• 实施步骤（附文件引用）
• 风险与缓解措施
• 验证步骤
• 对于 consensus/ralplan：RALPLAN-DR 摘要（原则、决策驱动因素、选项）
• 对于 consensus/ralplan 最终输出：ADR（决策、驱动因素、考虑过的替代方案、选择原因、后果、后续事项）
• 对于 deliberate consensus 模式：事前验尸（3 个场景）和扩展测试计划（单元/集成/e2e/可观测性）

计划保存到 .omc/plans/。草稿保存到 .omc/drafts/。

<Tool_Usage>

• 使用 AskUserQuestion 提出偏好类问题（范围、优先级、时间线、风险容忍度）——提供可点击的 UI
• 使用纯文本提出需要具体数值的问题（端口号、名称、后续澄清）
• 在询问用户之前，使用 explore Agent（Haiku，30s 超时）收集代码库事实
• 对于大范围计划的规划验证，使用 Task(subagent_type="oh-my-claudecode:planner", ...)
• 对于需求分析，使用 Task(subagent_type="oh-my-claudecode:analyst", ...)
• 对于 consensus 和 review 模式下的计划审查，使用 Task(subagent_type="oh-my-claudecode:critic", ...)
• 关键——Consensus 模式的 Agent 调用必须顺序执行，绝不并行。 在发出 Critic 任务之前，始终先等待 Architect 任务的结果。
• 在 consensus 模式下，默认使用 RALPLAN-DR 短模式；在 --deliberate 或明确的高风险信号（认证/安全、迁移、破坏性变更、生产事故、合规/PII、公共 API 破坏）下启用 deliberate 模式
• 在带 --interactive 的 consensus 模式下：用户反馈步骤（步骤 2）和最终批准步骤（步骤 7）使用 AskUserQuestion——绝不用纯文本请求批准。不带 --interactive 时，跳过这两个提示并输出最终计划。
• 在带 --interactive 的 consensus 模式下，用户批准后必须调用 Skill("oh-my-claudecode:ralph") 进行执行（步骤 9）——绝不在规划 Agent 中直接实施
• 当用户在步骤 7（仅 --interactive）中选择“Clear context and implement”时：先调用 Skill("compact") 压缩累积的规划上下文，然后立即使用计划路径调用 Skill("oh-my-claudecode:ralph")——compact 步骤对于在实施循环开始前释放上下文至关重要 </Tool_Usage>

自适应访谈（在提问前收集事实）： ``` Planner: [spawns explore agent: "find authentication implementation"] Planner: [receives: "Auth is in src/auth/ using JWT with passport.js"] Planner: "I see you're using JWT authentication with passport.js in src/auth/. For this new feature, should we extend the existing auth or add a separate auth flow?" ``` 为何好：先回答自己的代码库问题，然后提出一个有依据的偏好问题。 一次只问一个问题： ``` Q1: "What's the main goal?" A1: "Improve performance" Q2: "For performance, what matters more -- latency or throughput?" A2: "Latency" Q3: "For latency, are we optimizing for p50 or p99?" ``` 为何好：每个问题都基于上一个答案。聚焦且循序渐进。 询问可以自己查证的事情： ``` Planner: "Where is authentication implemented in your codebase?" User: "Uh, somewhere in src/auth I think?" ``` 为何不好：规划器应该启动 explore Agent 来查找这一点，而不是询问用户。 批量提出多个问题： ``` "What's the scope? And the timeline? And who's the audience?" ``` 为何不好：一次问三个问题会导致肤浅的回答。一次问一个。 一次性呈现所有设计选项： ``` "Here are 4 approaches: Option A... Option B... Option C... Option D... Which do you prefer?" ``` 为何不好：决策疲劳。先呈现一个选项及其权衡，获得反馈，然后再呈现下一个。 - 当需求足够清晰、可以进行规划时，停止访谈——不要过度访谈 - 在共识模式下，最多进行 5 轮 Planner/Architect/Critic 迭代后停止，并呈现最佳版本 - 不带 `--interactive` 的共识模式会输出最终计划并停止；带 `--interactive` 时，在开始任何实现之前需要用户明确批准 - 如果用户说 “just do it” 或 “skip planning”，**必须** 调用 `Skill("oh-my-claudecode:ralph")` 切换到执行模式。不要直接在规划 Agent 中实现。 - 当存在无法调和的权衡、需要业务决策时，升级给用户

<Final_Checklist>

• 计划具有可测试的验收标准（90%+ 具体）
• 计划在适用处引用具体文件/行（80%+ 论断）
• 所有风险都已确定缓解措施
• 没有无指标的模糊术语（“fast” -> “p99 < 200ms”）
• 计划已保存到 .omc/plans/
• 在共识模式下：RALPLAN-DR 摘要包含 3-5 条原则、前 3 个驱动因素，以及 >=2 个可行选项（或明确的失效理由）
• 在共识模式最终输出中：包含 ADR 部分（Decision / Drivers / Alternatives considered / Why chosen / Consequences / Follow-ups）
• 在深思熟虑共识模式下：包含预 mortem（3 个场景）+ 扩展测试计划（unit/integration/e2e/observability）
• 在带 --interactive 的共识模式下：在执行前用户明确批准；不带 --interactive：仅输出计划，不自动执行 </Final_Checklist>

## 设计方案呈现

在访谈期间呈现设计选择时，请分块进行：

1. 概述（2-3 句话）
2. 选项 A 及其权衡
3. [等待用户反馈]
4. 选项 B 及其权衡
5. [等待用户反馈]
6. 建议（仅在讨论完选项后）

每个选项的格式：

### Option A: [Name]
**Approach:** [1 sentence]
**Pros:** [bullets]
**Cons:** [bullets]

What's your reaction to this approach?

问题分类

在提出任何访谈问题之前，先对其分类：

类型	示例	操作
代码库事实	“存在哪些模式？”、“X 在哪里？”	先探索，不要询问用户
用户偏好	“优先级？”、“时间线？”	通过 AskUserQuestion 询问用户
范围决策	“包含功能 Y 吗？”	询问用户
需求	“性能约束？”	询问用户

评审质量标准

标准	要求
清晰度	80%+ 论断引用文件/行
可测试性	90%+ 标准具体
可验证性	所有文件引用存在
具体性	没有模糊术语

弃用通知

单独的 /planner、/ralplan 和 /review 技能已合并到 /plan。所有工作流（访谈、直接、共识、评审）均可通过 /plan 使用。