<使用时间> * 用户希望在实施之前进行计划——“计划这个”、“计划那个”、“让我们计划一下” * 用户希望为模糊的想法收集结构化的需求 * 用户希望审查现有计划——“审查此计划”，`--review` * 用户希望对计划达成多角度共识 -- `--consensus`, "ralplan" * 任务广泛或模糊，需要在编写任何代码之前确定范围 <何时不使用> * 用户想要自主的端到端执行——使用“autopilot”代替 * 用户希望立即开始编码并执行明确的任务——使用“ralph”或委托给执行者 * 用户提出一个可以直接回答的简单问题——只需回答即可 * 任务是一个具有明显范围的单一集中修复——跳过计划，直接执行在不了解需求的情况下跳入代码会导致返工、范围蔓延和错过边缘情况。计划提供结构化的需求收集、专家分析和质量控制计划，以便执行从坚实的基础开始。共识模式为高风险项目增加了多视角验证。 <执行策略> * 根据请求的具体情况自动检测访谈与直接模式 * 面试时一次问一个问题——切勿批量提问 * 在向用户询问之前通过“explore”代理收集代码库事实 * 计划必须符合质量标准：80% 以上的声明引用文件/行，90% 以上的标准是可测试的 * 共识模式默认全自动运行；添加“--interactive”以在草稿审核和最终批准步骤中启用用户提示 * 共识模式默认使用RALPLAN-DR短模式；使用“--deliberate”切换到深思熟虑模式，或者当请求明确表示高风险时（身份验证/安全、数据迁移、破坏性/不可逆更改、生产事件、合规性/PII、公共 API 破坏） ### 模式选择模式|触发|行为 ---|---|--- 采访 |广泛请求的默认设置 |互动需求收集直接| `--direct`，或详细请求|跳过面试，直接生成方案共识 | `--共识`，“ralplan” |规划者 -> 架构师 -> 批评者循环，直到与 RALPLAN-DR 结构化审议达成一致（默认情况下简短，“--deliberate”表示高风险）；在草稿和批准步骤中为用户提示添加“--interactive” 评论 | `--review`, "审查这个计划" |对现有计划的批评性评价 ### 面试模式（广泛/模糊的要求） 1. **对请求进行分类**：广泛（模糊动词，没有具体文件，涉及3个以上领域）触发访谈模式 2. **使用“AskUserQuestion”针对偏好、范围和约束提出一个重点问题** 3. **首先收集代码库事实**：在询问“您的代码使用什么模式？”之前，生成一个“探索”代理来找出答案，然后提出明智的后续问题 4. **建立在答案的基础上**：每个问题都建立在前一个答案的基础上 5. **咨询分析师** (Opus) 了解隐藏的需求、边缘情况和风险 6. **创建计划** 当用户表示准备就绪时：“创建计划”、“我准备好了”、“使其成为工作计划” ### 直接模式（详细要求） 1. **快速分析**：可选的简短分析师咨询 2. **创建计划**：立即生成全面的工作计划 3. **审查**（可选）：根据要求进行评论家审查 ### 共识模式（`--consensus`/“ralplan”） **RALPLAN-DR 模式**：**短**（默认，有界结构）和 **故意**（用于“--故意”或明确的高风险请求）。两种模式都保留相同的 Planner -> Architect -> Critic 序列和相同的“AskUserQuestion”门。 1. **规划师**在任何架构师审查之前创建初始计划和紧凑的 **RALPLAN-DR 摘要**。摘要**必须**包括： * **原则** (3-5) * **决策驱动因素**（前 3 名） * **可行的选项** (>=2) 每个选项都有有限的优点/缺点 * 如果只剩下一个可行的选择，则被拒绝的替代方案有明确的**无效理由** * 在**深思熟虑的模式**中：**事前分析**（3个故障场景）和**扩展测试计划**，涵盖**单元/集成/e2e/可观察性** 2. **用户反馈**_（仅--interactive）_：如果使用“--interactive”运行，**必须**使用“AskUserQuestion”来呈现计划草案**加上用于早期方向调整的 RALPLAN-DR 原则/决策驱动因素/选项摘要**以及以下选项： * **继续审查** — 发送给架构师和评论家进行评估 * **请求更改** — 返回步骤 1，并纳入用户反馈 * **跳过审核** — 直接进入最终批准（步骤 7）如果不使用 `--interactive` 运行，则自动继续审核（步骤 3）。 3. **架构师** 使用 `Task(subagent_type="oh-my-claudecode:architect", ...)` 审查架构的健全性。架构师审查**必须**包括：针对首选选项的最强烈的钢铁侠反驳（对立），至少一种有意义的权衡张力，以及（如果可能）一条综合路径。在深思熟虑的模式下，架构师应该明确标记违反原则的行为。 **等待此步骤完成，然后再继续步骤 4。** 不要并行运行步骤 3 和 4。 4. **Critic** 使用 `Task(subagent_type="oh-my-claudecode:critic", ...)` 根据质量标准进行评估。批评家**必须**验证原则-选项的一致性、公平的替代探索、风险缓解的清晰度、可测试的验收标准和具体的验证步骤。批评家**必须**明确拒绝肤浅的替代方案、驱动因素矛盾、模糊的风险或薄弱的验证。在深思熟虑的模式下，Critic **必须**拒绝缺失/薄弱的事前分析或缺失/薄弱的扩展测试计划。仅在步骤 3 完成后运行。 5. **重新审查循环**（最多 5 次迭代）：如果 Critic 拒绝，则执行此闭环：收集来自架构师 + 批评家的所有拒绝反馈 b．将反馈传递给计划员以制定修订计划 c． **返回步骤 3** — 建筑师审查修改后的计划 d． **返回步骤 4** — Critic 评估修订后的计划 e。重复直到 Critic 批准或最多 5 次迭代达到 f。如果未经批准达到最大迭代次数，则通过“AskUserQuestion”向用户呈现最佳版本，并注意尚未达成专家共识 6. **应用改进**：当审阅者批准改进建议时，将所有接受的改进合并到计划文件中，然后再继续。最终共识输出**必须**包括**ADR**部分，其中包含：**决策**、**驱动因素**、**考虑的替代方案**、**为什么选择**、**后果**、**后续行动**。具体来说：从架构师和评论家的回复中收集所有改进建议 b．对建议进行重复删除和分类 c.使用已接受的改进更新“.omc/plans/”中的计划文件（添加缺失的细节、完善步骤、加强验收标准、ADR 更新等） d．请注意计划末尾的简短变更日志部分中应用了哪些改进 7. 在 Critic 批准时（已应用改进）：_（仅 --interactive）_ 如果使用 `--interactive` 运行，请使用 `AskUserQuestion` 来呈现包含以下选项的计划： * **批准并执行** — 通过 ralph+ultrawork 继续实施 * **通过团队批准和实施** — 通过协调的并行团队代理继续实施 * **清除上下文并实施** - 首先压缩上下文窗口（计划后上下文很大时推荐），然后通过 ralph 使用保存的计划文件开始新的实施 * **请求更改** — 返回步骤 1 并提供用户反馈 * **拒绝** — 完全放弃计划如果不使用 `--interactive` 运行，则输出最终批准的计划并停止。不要自动执行。 8. _(--仅限交互)_ 用户通过结构化的“AskUserQuestion” UI 进行选择（切勿以纯文本形式请求批准） 9. 用户批准时（仅交互式）： * **批准并执行**：**必须**使用“.omc/plans/”中批准的计划路径作为上下文调用“Skill("oh-my-claudecode:ralph")”。不要直接实施。不要在规划代理中编辑源代码文件。 ralph 技能通过 ultrawork 并行代理处理执行。 * **通过团队批准和实施**：**必须** 使用“.omc/plans/”中批准的计划路径作为上下文调用“Skill("oh-my-claudecode:team")”。不要直接实施。团队技能协调分阶段管道中的并行代理，以便更快地执行大型任务。 * **清除上下文并实施** ：首先调用 `Skill("compact")` 来压缩上下文窗口（减少规划过程中累积的令牌使用量），然后使用 `.omc/plans/` 中批准的计划路径调用 `Skill("oh-my-claudecode:ralph")`。当规划会话后上下文窗口已满 50% 以上时，建议使用此路径。 ### 审阅模式（`--review`） 1.从`.omc/plans/`读取计划文件 2. 使用 `Task(subagent_type="oh-my-claudecode:critic", ...)` 通过 Critic 进行评估 3. 返回判决：批准、修订（有具体反馈）或拒绝（需要重新规划） ### 计划输出格式每个计划包括： * 需求摘要 * 验收标准（可测试） * 实施步骤（附文件参考） * 风险和缓解措施 * 验证步骤 * 对于共识/ralplan：**RALPLAN-DR 摘要**（原则、决策驱动因素、选项） * 对于共识/ralplan 最终输出：**ADR**（决策、驱动因素、考虑的替代方案、选择原因、后果、后续行动） * 对于深思熟虑的共识模式：**事前分析（3 个场景）** 和 **扩展测试计划**（单元/集成/e2e/可观察性）计划保存到“.omc/plans/”。草稿转到“.omc/drafts/”。 <工具_用法> * 使用“AskUserQuestion”进行偏好问题（范围、优先级、时间表、风险承受能力）——提供可点击的 UI * 对于需要特定值的问题使用纯文本（端口号、名称、后续说明） * 在询问用户之前使用“explore”代理（俳句，30 秒超时）收集代码库事实 * 使用 `Task(subagent_type="oh-my-claudecode:planner", ...)` 对大范围计划进行规划验证 * 使用 `Task(subagent_type="oh-my-claudecode:analyst", ...)` 进行需求分析 * 使用 `Task(subagent_type="oh-my-claudecode:critic", ...)` 在共识和审核模式下进行计划审核 * **关键 - 共识模式代理调用必须是连续的，绝不是并行的。** 在发出关键任务之前始终等待架构师任务结果。 * 共识模式下，默认为RALPLAN-DR短模式；对“--deliberate”或明确的高风险信号启用故意模式（身份验证/安全、迁移、破坏性更改、生产事件、合规性/PII、公共 API 破坏） * 在使用 `--interactive` 的共识模式下：使用 `AskUserQuestion` 进行用户反馈步骤（步骤 2）和最终批准步骤（步骤 7）——切勿以纯文本形式请求批准。如果没有 `--interactive`，则跳过两个提示并输出最终计划。 * 在使用 `--interactive` 的共识模式下，在用户批准后 **必须** 调用 `Skill("oh-my-claudecode:ralph")` 来执行（步骤 9）——切勿直接在规划代理中实施 * 当用户在步骤 7 中选择“清除上下文并实施”时（--仅限交互）：首先调用 `Skill("compact")` 以压缩累积的计划上下文，然后立即使用计划路径调用 `Skill("oh-my-claudecode:ralph")` -- 紧凑步骤对于在实施循环开始之前释放上下文至关重要 <升级和停止条件> * 当需求足够清晰以进行计划时停止面试——不要过度面试 * 在共识模式下，5次Planner/Architect/Critic迭代后停止并呈现最佳版本 * 没有`--interactive`的共识模式输出最终计划并停止；使用“--interactive”，在任何实施开始之前需要明确的用户批准 * 如果用户说“就做吧”或“跳过计划”，**必须**调用 `Skill("oh-my-claudecode:ralph")` 来转换到执行模式。不要直接在规划代理中实施。 * 当存在不可调和的权衡需要业务决策时升级给用户 <最终清单> * 计划具有可测试的验收标准（90%+ 混凝土） * 计划参考适用的特定文件/行（80%+ 声明） * 所有风险均已确定缓解措施 * 没有没有指标的模糊术语（“fast”->“p99 < 200ms”） * 计划保存到 `.omc/plans/` * 在共识模式下：RALPLAN-DR 摘要包括 3-5 个原则、前 3 个驱动因素和 >=2 个可行选项（或明确的失效理由） * 在共识模式下最终输出：包括 ADR 部分（决策/驱动因素/考虑的替代方案/为什么选择/后果/后续行动） * 在深思熟虑的共识模式下：包括事前分析（3个场景）+扩展测试计划（单元/集成/e2e/可观察性） * 在带有“--interactive”的共识模式下：用户在任何执行之前明确批准；没有`--interactive`：仅计划输出，不自动执行在面试中提出设计选择时，将它们分块： 1. **概述**（2-3句话） 2. **选项 A** 需要权衡 3.【等待用户反应】 4. **选项 B** 需要权衡 5.【等待用户反应】 6. **建议**（仅在讨论选项之后）每个选项的格式： ### 选项 A：[姓名] **做法：** [1句话] **优点：** [项目符号] **缺点：** [要点] 您对这种做法有何反应？ ## 问题分类在提出任何面试问题之前，先对其进行分类：类型 |示例 |行动 ---|---|--- 代码库事实 | “存在什么模式？”、“X 在哪里？” |先探索，不要询问用户用户偏好| “优先级？”、“时间线？” |通过 AskUserQuestion 询问用户范围决策 | “包括功能Y？” |询问用户要求 | “性能限制？” |询问用户 ## 审查质量标准标准|标准型 ---|--- 清晰度| 80% 以上的声明引用文件/行可测试性| 90%以上的标准是具体的验证|所有文件引用都存在特异性|没有含糊的条款 ## 弃用通知单独的“/planner”、“/ralplan”和“/review”技能已合并到“/plan”中。所有工作流程（访谈、直接、共识、审查）都可以通过“/plan”获得。

计划

包含技能