OmX Prometheus 启发的审慎规划配方（prometheus-inspired-deliberation）完整实践指南

导读

本文面向使用 OmX（Oh My codeX）工作流的开发者与 AI Agent 编排者，详细讲解仓库中一份实验性（experimental）非官方配方——docs/recipes/prometheus-inspired-deliberation.md。该配方在 canonical 的 $deep-interview -> $ralplan -> $ultragoal 主路径之外，提供一份可选的、由人工把关的额外检查清单，用于在需求澄清、共识规划与目标执行之间插入系统性的挑战与验证环节。读完本文，你将掌握：如何在 OmX 现有技能体系内完成一次"多一层审慎"的计划评审、三个必须人工追问的挑战问题是什么、为什么不能在当前仓库中调用 $prometheus-strict 或引入 Metis/Momus/Oracle 类 agent，以及如何复用既有 artifact 而不引入新的工作流表面。

一、配方定位：实验性 Recipe，而非正式技能

1.1 它是什么

在 OmX 的技能体系中，正式能力通常以 skills/ 目录下的 SKILL.md 形式存在（例如 skills/deep-interview/SKILL.md、skills/ralplan/SKILL.md、skills/ultragoal/SKILL.md），并可能挂接 keyword、hook 或 native-agent 表面。而本文关联文档在开篇就明确声明了自己的身份：

This is a non-canonical recipe, not an active OMX skill, keyword, hook, or native-agent surface.

也就是说，prometheus-inspired-deliberation 不是一个可以被 $ 前缀直接调用的技能，也没有注册任何 keyword、hook 或原生 agent 表面。它只是存放在 docs/recipes/ 下的一份"配方（recipe）"文档——一种经过整理的流程模板，供操作者在需要额外的人工检查清单时手动参考。

1.2 灵感来源与许可边界

文档同时给出了明确的"credit"声明：本配方的灵感来自高层级的 OMO Prometheus 概念（code-yeongyu/oh-my-openagent），但 OmX 仓库仅以 MIT 许可下的"概念级指导（concept-only guidance）" 方式重新实现，不复制 OMO 的源码文本、prompt、运行时代码或工作流实现。这意味着你在使用本配方时，接触到的全部是 OmX 自身的技能体系与 artifact 约定，不需要、也不应该引入任何外部实现。

1.3 当前仓库中 $prometheus-strict 的真实状态

配方边界中有一句容易被忽略但极其重要的约束："Do not invoke $prometheus-strict; no such canonical active skill is shipped."（不要调用 $prometheus-strict，仓库并未随附任何这样的 canonical 激活技能。）

从源码证据看，这句话在当前仓库中是字面成立的：在 src/hooks/sunset-stub.ts 的 REMOVED_SKILLS 表中，可以看到以下条目（对应 src/hooks/sunset-stub.ts#L91-L106）：

"prometheus-strict": {
  message: 'Skill "$prometheus-strict" has been removed. Use "$plan" for planning instead.',
},
"prometheus-strict-metis": {
  message: 'Prompt "$prometheus-strict-metis" has been removed. Use "$plan" instead.',
},
"prometheus-strict-momus": {
  message: 'Prompt "$prometheus-strict-momus" has been removed. Use "$plan" instead.',
},
"prometheus-strict-oracle": {
  message: 'Prompt "$prometheus-strict-oracle" has been removed. Use "$plan" instead.',
},

也就是说，$prometheus-strict 及其 Metis/Momus/Oracle 变体都已被下架（removed），sunset stub 会引导用户改用 $plan。另有一份历史审计记录 docs/audit/skills-agents-bloat-audit/inventory.md 保留了过去 prometheus-strict 及其 Metis/Momus/Oracle 子角色的登记信息（曾作为 active 技能存在），而 docs/recipes/prometheus-strict/dogfood-2026-05-22.md 也保留了曾经的 dogfood 演练记录——这些都说明该主题在仓库中经历了"存在 → 移除"的过程。keyword 探测侧，src/hooks/keyword-detector.ts#L1095 的 COORDINATED_WORKFLOW_SUBJECT 正则仍把 prometheus(?:-strict)? 列为可识别的工作流主题之一，但配方文档与 sunset stub 共同确认：当前没有任何可激活的 canonical 实现。

结论：本配方的作用，是用一套手工的、非正式的三问挑战法，在 OmX 现有技能栈上复现"Prometheus 式审慎"，而不是复活任何已移除的技能。

二、前置知识：配方依赖的 canonical 主路径

在深入配方步骤之前，先明确它叠加在哪条 canonical 路径之上。配方原文给出的主路径是：

$deep-interview -> $ralplan -> $ultragoal

这与 skills/deep-interview/SKILL.md 中记录的 Canonical Autopilot Entry Pipeline 完全一致：

autopilot -> deep-interview -> ralplan -> ultragoal

三个阶段各自的职责（依据各 SKILL.md）：

阶段	技能	核心职责	关键产物
需求澄清	$deep-interview	苏格拉底式澄清循环，量化模糊度并压测假设	.omx/specs/deep-interview-{slug}.md、.omx/interviews/{slug}-*.md
共识规划	$ralplan	Planner → Architect → Critic 顺序评审，形成共识计划	.omx/plans/prd-*.md、.omx/plans/test-spec-*.md、ralplan_execution_handoff
目标执行	$ultragoal	将计划转为持久的 repo 原生多目标执行与验证	.omx/ultragoal/brief.md、.omx/ultragoal/goals.json、.omx/ultragoal/ledger.jsonl

配方并不是要替换其中任何一环，而是在 $ralplan 完成之后、$ultragoal 启动之前，插入一次人工的、针对计划的挑战式审查。换句话说：它是把"多一道审慎"落在 规划产物上，而不是落在"再开一条新工作流"上。

三、配方五步详解

配方正文给出了 5 个步骤，下面逐条展开，并结合各 SKILL.md 的机制说明每一步"应该怎么做、产出什么、为什么这么做"。

第 1 步：运行 $deep-interview，直到关键要素显式化

配方要求：

Run $deep-interview until requirements, non-goals, acceptance criteria, and unresolved assumptions are explicit.

即：需求（requirements）、非目标（non-goals）、验收标准（acceptance criteria）与未决假设（unresolved assumptions）都必须显式化。

$deep-interview 正是为此设计的意图优先澄清循环。依据 skills/deep-interview/SKILL.md：

• 它提供四个深度档位：--quick（阈值 <= 0.30，最多 5 轮）、--standard（默认，阈值 <= 0.20，最多 12 轮）、--deep（阈值 <= 0.15，最多 20 轮）、--autoresearch（研究任务专用）。
• 模糊度按加权维度计算，绿色地（greenfield）公式为 ambiguity = 1 - (intent × 0.30 + outcome × 0.25 + scope × 0.20 + constraints × 0.15 + success × 0.10)；棕地（brownfield）则额外引入 context 维度（权重 0.10）。
• 存在两条强制性就绪门（readiness gates）：Non-goals 必须显式、Decision Boundaries 必须显式，否则即使加权模糊度达标也不能结晶（crystallize）。
• 完成阶段会产出两份 artifact：访谈纪要写入 .omx/interviews/{slug}-{timestamp}.md，执行就绪规格写入 .omx/specs/deep-interview-{slug}.md。

对配方而言，第 1 步的"完成判据"不应只看模糊度数字，而要逐项核对：需求是否被拆成意图/结果/范围/约束/成功标准；非目标是否显式列出；验收标准是否可测试；残留假设是否被记录并给出解决状态。这正是 $deep-interview 的 spec 结构（含 Assumptions exposed + resolutions、Pressure-pass findings）所强制的。

第 2 步：运行 $ralplan，并要求计划显式陈述五项内容

配方要求计划（plan）必须显式包含：

1. objective and non-goals —— 目标与非目标；
2. evidence versus assumptions —— 证据与假设的区分；
3. verification gates —— 验证门；
4. rollback or escalation triggers —— 回滚或升级触发条件；
5. whether any $team lanes are truly independent —— 是否存在真正独立的并行 lane。

对照 skills/ralplan/SKILL.md，$ralplan 是 Autopilot 中 $deep-interview 与 $ultragoal 之间的 共识规划阶段（consensus planning stage），其核心机制恰好支持这五项要求：

• Planner → Architect → Critic 顺序评审：Planner 首先生成自适应计划与 RALPLAN-DR 摘要（包含 Principles 3-5 条、Decision Drivers 前 3 个、Viable Options ≥2 个及权衡），Architect 评审架构健全性并给出最强钢人式反题（steelman antithesis）与真实权衡张力，Critic 依据质量标准把关原则-选项一致性、风险缓解清晰度、可测试验收标准与具体验证步骤。
• --deliberate 模式针对高风险工作强制加入 pre-mortem（3 个失败场景）与扩展测试计划（单元/集成/e2e/可观测性）。
• 可测试验收标准是 Critic 的强制评审项，天然对应配方第 3 项"verification gates"。
• 计划的持久化产物为 .omx/plans/prd-*.md 与 .omx/plans/test-spec-*.md，但这两类文件只是规划 artifact，不是共识证据；必须存在顺序的 Architect→Critic 评审记录与 ralplan_execution_handoff（含 authorized、reason、authorized_at、session_id、review_cycle、source），计划才算真正可交接。

需要特别提醒：$ralplan 是纯规划模式，在无显式执行交接前，不得在 ralplan 会话内直接写实现代码；它只允许写 .omx/context/、.omx/plans/、.omx/specs/ 与必要的 .omx/state/ 记录。

第 3 步：在 $ultragoal 之前，用三个问题人工挑战计划

这是整个配方的核心增量——三道人工质询：

1. What ambiguity could still change implementation scope? 还有哪些歧义可能改变实现范围？
2. What verification would catch the highest-cost failure? 什么样的验证能捕获代价最高的失败？
3. What work split would create ownership conflicts or merge risk? 什么样的分工会产生所有权冲突或合并风险？

这三问分别对准三条风险轴线：

问题	对准的风险	与既有机制的呼应
歧义 vs 范围	需求残留歧义在实现期放大范围	$deep-interview 的模糊度评分与 Non-goals/Decision Boundaries 就绪门
验证 vs 最高成本失败	验证策略与风险不成比例	$ralplan 的 verification gates、--deliberate 的 pre-mortem 与扩展测试计划
分工 vs 冲突/合并风险	并行 lane 之间的边界与集成摩擦	$team 的并行 lane 划分，以及 $ultragoal 的 checkpoint 汇总机制

这一问的巧妙之处在于：它把"审慎"从流程前置（继续加访谈轮次）转向产物审查（对已形成的计划做对抗式复核），因此成本低、见效快。

第 4 步：若答案改变了计划，修订 $ralplan artifact，而不是新建工作流表面

If the answers change the plan, revise the $ralplan artifact instead of creating a new workflow surface.

这是配方最重要的纪律约束。三问挑战若暴露了计划缺陷，正确的动作是回到 ralplan artifact 本身去修订（重新走 Planner 修订、必要时重跑 Architect→Critic 复核循环——$ralplan 的 re-review loop 最多支持 5 次迭代，非 APPROVE 的 Critic 判定必须触发完整闭环：收集反馈 → Planner 修订 → Architect 重审 → Critic 再评）。而不是为了容纳这些修订去发明新的技能、新的 keyword、新的 hook 或新的 native-agent 表面。

这一点与第 1.3 节讲到的仓库现状形成呼应：OmX 的取向是"收敛到既有 canonical 技能与 artifact 约定"，任何超出既有表面的能力都需要经得起 bloat audit 之类的审视（可参考 docs/audit/skills-agents-bloat-audit/ 下的审计文档）。配方的第 4 步正是把这种"少即是多"的取向落实为一条可操作规则。

第 5 步：将获批计划交给 $ultragoal，仅在确有并行价值时在 Ultragoal story 内启动 $team

Hand the approved plan to $ultragoal; launch $team only inside a concrete Ultragoal story when parallel lanes are warranted.

依据 skills/ultragoal/SKILL.md，$ultragoal 将获批计划转化为持久的 repo 原生多目标执行：

omx ultragoal create-goals --brief "<brief>"
omx ultragoal create-goals --brief-file <path>
cat <brief> | omx ultragoal create-goals --from-stdin

随后进入执行循环：omx ultragoal complete-goals 读取交接 → 完成单个 OMX story → 以 omx ultragoal checkpoint --goal-id <id> --status complete --evidence "<evidence>" --codex-goal-json <fresh-get-goal-json-or-path> 做中间 checkpoint；受阻/失败 story 用 --status blocked|failed 记录证据，重试用 --retry-failed。

$team 则用于并行 lane：依据 skills/team/SKILL.md，其启动形状为 omx team [N:agent-type] "<task>"，依赖 tmux 会话与 .omx/state/team/<name>/ 下的任务与邮箱状态。配方强调的"only inside a concrete Ultragoal story"对应 Team 技能中的 Team and Ultragoal 桥接：当 leader 持有 .omx/ultragoal/goals.json 时，worker 只返回任务证据，由 leader 用最新 Codex get_goal 快照执行 omx ultragoal checkpoint 汇总——即并行执行必须被纳管在某个具体的 Ultragoal story 目标之下，而不是游离在外。

四、边界约束：三条"禁止事项"及其仓库依据

配方的 Boundaries 部分明确列出三条禁令，每一条都能在当前仓库找到对应依据：

4.1 禁止调用 $prometheus-strict

Do not invoke $prometheus-strict; no such canonical active skill is shipped.

依据 src/hooks/sunset-stub.ts#L91-L106，prometheus-strict 已在 REMOVED_SKILLS 表中登记移除，并引导用户改走 $plan。src/hooks/sunset-stub.ts 还导出了 isRemovedSkill(token) 与 formatRemovedSkillError(rawToken) 等辅助函数（见 src/hooks/sunset-stub.ts#L117-L125），说明"识别已移除技能并给出友好错误"是运行时 hook 的正式行为。

4.2 禁止为配方新增 Metis/Momus/Oracle prompt-backed native agents

Do not add Metis/Momus/Oracle prompt-backed native agents for this recipe.

prometheus-strict-metis、prometheus-strict-momus、prometheus-strict-oracle 同样在 REMOVED_SKILLS 中被登记为已移除（提示改用 $plan）。历史审计文档 docs/audit/skills-agents-bloat-audit/inventory.md 记录了它们曾以 frontier-orchestrator / coordination 角色存在，但当前仓库不再提供。因此配方要求把"挑战者"角色由人工三问承担，而不是重新引入 prompt-backed 原生 agent。

4.3 禁止创建单独的 Prometheus artifact 约定

Do not create a separate Prometheus artifact convention; use existing $deep-interview, $ralplan, and $ultragoal artifacts.

这一条再次强调：三问挑战的结果若需要落地，应当回写既有 artifact（修订 .omx/plans/、.omx/specs/ 下的既有文件），而不是新建一套 prometheus-* 命名空间。这与第 4 步"revise the $ralplan artifact instead of creating a new workflow surface"互相印证，共同构成配方的核心设计哲学：审慎是流程上的姿态，不是结构上的新增。

五、何时使用本配方：适用前提与限制

综合文档与仓库现状，本配方适用于以下场景，也存在明确限制：

适用场景

• 操作者希望在 canonical 主路径上增加额外的人工检查清单，尤其是高风险、大范围或多 lane 并行可能引入的计划。
• 计划已经过 $deep-interview 澄清、但尚未进入 $ultragoal 执行，且操作者对"计划是否真的准备好了"没有把握。
• 团队（人类）需要一处结构化的、可复用的"计划质询模板"——三问挑战法恰好提供了这一模板。

不适用 / 限制

• 它不是可 $ 调用的技能，也没有 keyword/hook/native-agent 表面，无法被运行时自动触发；它依赖操作者主动执行。
• 它不提供新的 artifact 格式、新的 agent 角色或新的运行时能力；所有产出仍落在 $deep-interview、$ralplan、$ultragoal（必要时 $team）的既有 artifact 与命令之上。
• 它与 $prometheus-strict 及其 Metis/Momus/Oracle 变体没有任何运行时关系，后者在当前仓库已被移除（src/hooks/sunset-stub.ts#L91-L106），不要期望调用它们。

六、一次完整操作的落地清单

将配方落到一次真实操作上，完整链路如下：

1. 运行 $deep-interview --standard <任务描述>，直到非目标与决策边界显式、残留假设被记录；确认 .omx/specs/deep-interview-{slug}.md 生成。
2. 运行 $ralplan <spec-path>（或 --interactive 版），核对计划是否显式包含：目标与非目标、证据 vs 假设、验证门、回滚/升级触发条件、$team lane 独立性说明；确认 PRD/test-spec 与顺序的 Architect→Critic 评审证据、ralplan_execution_handoff 均已持久化。
3. 启动前，由操作者（或主规划人）就计划回答三问：
   • 还有什么歧义可能改变实现范围？
   • 哪一项验证能捕获代价最高的失败？
   • 怎样的分工会产生所有权冲突或合并风险？
4. 若答案指向计划缺陷：回到 $ralplan 修订计划并重跑评审闭环（re-review loop 上限 5 次），不新建任何技能/表面。
5. 计划获批后：omx ultragoal create-goals --brief-file <spec-path> 建目标，逐 story 执行并用 omx ultragoal checkpoint 打点；仅当某个具体 Ultragoal story 内确实存在可独立推进的并行 lane 时，才以 omx team [N:agent-type] "<task>" 启动 $team，并由 leader 用 checkpoint 汇总 worker 证据。

这套流程的最终效果是：在保持 OmX 既有 canonical 技能、artifact 与命令不变的前提下，通过一道额外的人工审慎门，把"计划是否真正经得起推敲"这个容易在自动化流水线中被跳过的环节显式地补上。