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

计划

包含技能