prometheus-strict

Prometheus Strict

受 OMO Prometheus 高层概念启发、以净室方式实现的 OMX 规划工作流。本技能不会复制 OMO 的实现、提示词、措辞、控制流或运行时代码。它是在本仓库的 MIT 许可技能约定下对该理念的重新实现。

致谢：灵感来自 OMO Prometheus（code-yeongyu/oh-my-openagent），基于 MIT 从概念重新实现。

当歧义仍存在风险时，Prometheus Strict 会在执行前制定一份严谨的计划。它将三种规划声音分开：Metis 澄清需求，Momus 质疑假设与验证缺口，Oracle 综合出可交接的 OMX 原生计划。

输出是一份仅用于规划的产物，供 $ultragoal 使用，并在独立工作流合理时供 $team 使用。当持久化产物有用时，将最终计划存储或请求存储到 .omx/plans/prometheus-strict/ 下。

<Use_When>

• 任务足够重要，浅层计划可能导致错误的工作。
• 需求已部分已知，但验收标准、边界、风险或验证尚不完整。
• 用户希望在执行前进行严格的访谈。
• 未来的 $ultragoal 故事需要持久化的范围、测试和交接顺序。
• 可能需要团队拆分，但各工作流尚不安全，无法分配。 </Use_When>

<Do_Not_Use_When>

• 用户要求立即实现一个清晰、低风险的变更；请使用常规执行器路径。
• 任务只是仓库查找或解释；视情况使用 explore/analyze。
• 用户需要在代码变更后进行对抗性执行 QA；请使用 $ultraqa。
• 用户想要 hook 行为、Sisyphus 行为或 start-work 移植。这些是明确的非目标。 </Do_Not_Use_When>

<Why_This_Exists> OMX 已有 $plan、$ralplan 和 $deep-interview。Prometheus Strict 存在的意义在于一个更窄的场景：一条显式的净室严格规划通道，具有明确的澄清、批判和综合角色，外加持久化的 .omx/plans/prometheus-strict/ 交接契约。它不是执行工作流的替代品。 </Why_This_Exists>

<Execution_Policy>

• 保持仅规划。除非用户之后启动单独的执行工作流，否则在本技能期间不要编辑源代码。
• 保持净室边界。不要复制或模仿 OMO 的措辞、源代码、提示词、运行时行为或控制流。
• 保持非目标可见：无 hook 实现。无 Sisyphus/start-work 移植。无自动外部生产操作。
• 当答案会实质性改变范围、安全性或验证时，以批量轮次提出高杠杆问题。仅在依赖性问题链中，即下一个问题取决于前一个答案时，才保留一次一个的提问方式。
• 如果有安全的假设可用，请陈述该假设并继续。
• 在需要时使用仓库读取，以使路径、测试和交接命令具体化。
• 在 Metis 规划期间，对每个非平凡意图运行提问前的研究扇出，除非任务平凡、所引用的规格自包含，或缓存证据已覆盖同一范围；在询问用户之前，使用 explore 获取仓库事实，并使用精确廉价的 gpt-5.6-terra researcher 通道获取外部文档 / OSS 参考。Prometheus Strict 每轮最多可扇出 2 explore + 4 researcher 个 Agent，因此广度来自更多以引用为重点的小型研究者，而 Metis/Momus/Oracle 保持更强的判断角色。
• 仅当 Oracle 识别出独立、有界、可验证的工作流时，才推荐 $team。

结构化问题界面

向用户提出的每个 Metis/Momus/Oracle 问题都必须经过与界面相匹配的结构化问题路径。纯文本提问是最后的后备手段，而非默认方式。

• 在已附加的 tmux OMX 运行时中，使用 omx question 作为 OMX 拥有的结构化问题界面（这是 Prometheus Strict 中 AskUserQuestion 的等价物）。从已附加的 tmux Bash/工具路径调用时，请在命令前加上 OMX_QUESTION_RETURN_PANE=$TMUX_PANE（或具体的 %pane 值），以便保留 leader 窗格的返回目标。
• 将相互独立的高价值问题批量合并为单次 questions[] 数组调用：范围、约束、非目标、交付物、安全边界和验收标准通常是相互独立的，必须批量合并到一个结构化表单中，让用户在一个面板中一次性作答。仅在后续问题依赖前一个答案的依赖式问题链中，才保留一次一个问题的方式。
• 在检查放行规则、提出另一轮问题或移交之前，等待 omx question 的 JSON 答案；优先使用 answers[] / answers[i].answer，仅在兼容性后备场景下使用旧版顶层 answer。每轮 answers[] 批量作答之后，在提出下一个问题或移交之前，至少运行 两轮补缺扫描：第 1 轮将用户答案吸纳进检查清单；第 2 轮重新扫描仓库上下文、先前对话轮次、研究扇出证据和保守默认值，以吸收非 CRITICAL 的残留缺口。
• 最少发布两轮问题：当 Metis 发布任何面向用户的问题轮次时，除非敌意/<turn_aborted> 或第 5 轮上限强制退出，否则不得在第 1 轮后移交；只有在第 2 轮已发布并处理完毕后才允许移交。当未发布任何问题时，零问题、完整检查清单的移交仍然有效。
• 轮次之间的规划必须积极利用证据：在第 1 轮答案和两轮补缺扫描之后，刷新或复用 <research_fan_out> 的探索/研究员证据，重新运行规格预填充，并仅基于残留的 CRITICAL 缺口构建第 2 轮。
• 在 tmux 之外，当有可用的原生结构化输入工具时，使用该工具。
• 当两种结构化界面都无法渲染时（非 tmux 的 Codex CLI、管道运行、CI），将该轮的独立问题列为编号的纯文本块（Q1: ... Q2: ... Q3: ...），并在一个用户轮次中等待所有答案；不要拆分为多次独立往返。
• 当尚未达到放行标准时，多轮访谈确实是预期行为；每一轮都是一个批量表单（或其纯文本后备形式），绝不拆分到多个表单中。

清单确认

访谈由确定性的清单确认机制驱动，而非主观判断“感觉够了”。当 6 项清单全部为 YES 时，退出 Metis 访谈循环：目标／范围 IN+OUT／验收标准／测试策略／交接目标／没有未解决的 CRITICAL。每项均按照 <Turn_Termination_Rules> 中定义的三态进行评估。

访谈轮数上限为 5，以防止无限延续。如果到第 5 轮仍未完成清单确认，则将剩余 UNKNOWN 项作为明确标注的 <unresolved_blocker> 条目交给 Oracle，供其后续处理。

敌意／不作答退出：如果用户在某一轮的回复中包含拒绝信号（1–2 个字符的不作答、敷衍的 알아서／“你决定”／“随便”模式、带有脏话的回复，或上一轮出现 <turn_aborted>），则该轮答案无效——任何清单项都不会因此变为 YES；立即退出访谈循环，并将未解决的缺口转交给 <silent_absorption>（对于敷衍推给他人处理的情况），或通过 hostility_exit 交回用户处理（对于愤怒／中止轮次的情况）。完整模式列表和路由规则请参阅 prometheus-strict-metis 的 <hostility_detection>。 </Execution_Policy>

<Turn_Termination_Rules> 每个 Prometheus Strict 回合都必须以以下终止方式之一结束，且只能有一种。禁止只做总结或说“我觉得可以结束了”。

6 项清单为：目标／范围 IN+OUT／验收标准／测试策略／交接目标／没有未解决的 CRITICAL。当某一清单项满足 USER_ANSWERED ∪ ABSORBED_WITH_CITATION ∪ INFERRED_FROM_SPEC 时，该项为 YES。只有 UNKNOWN（没有答案、没有引用依据、无法从规范推断）才计为 NO。

• (a) omx question 批次：当至少有一个 CRITICAL 问题经 <gap_triage> 和 <self_review> 后仍需处理时使用。该批次就是本轮；等待收到 answers[] 后再继续。
• (b) 明确交接：当 6 项清单全部为 YES 时使用。确认完成后，将 Metis 交给 Momus；批评审查后，将 Momus 交给 Oracle；Pass 2 综合后，将 Oracle 交给用户，或将未解决项作为 <unresolved_blocker> 条目继续处理。
• (c) 阻止并停止：通过 <hostility_detection> 检测到敌意／<turn_aborted>，且子类型为 hostility_exit 时使用；或者下一步操作具有破坏性、需要凭据、涉及外部生产环境，且无法安全地采用默认方案时使用。

边缘情况：

1. 没有待提问的问题但清单已完成 → 选择 (b) 明确交接。不要输出空的 omx question 表单。
2. 第 5 轮仍未完成清单 → 选择 (a)，再发送一批问题，并标注仍未解决的 UNKNOWN 项；或者选择 (b)，将 UNKNOWN 项作为 <unresolved_blocker> 条目交给 Oracle，供其后续处理。
3. 敌意／<turn_aborted> → 对于愤怒、脏话或通过 hostility_exit 中止的轮次，选择 (c)；对于敷衍推给他人处理（알아서／“你决定”），选择 (b)，并标注已吸收处理的缺口。 </Turn_Termination_Rules>

### 1. 接收需求与安全边界

重述目标结果、已知约束、交付物、验证预期和停止条件。确认本轮仅进行规划，还是用户也要求执行后续操作。

如果提示中包含破坏性操作、需要凭据的操作、外部生产环境操作，或实质性改变范围的决策，应暂缓这些决策，等待用户明确确认。否则，继续规划流程。

2. Metis 访谈（迭代式、清单清零）

使用 prometheus-strict-metis 作为访谈声音。当原生子代理可用时，调用专用 Agent；否则在上下文内运行同一角色，不编辑文件。

Metis 会发现成功标准、非目标、证据与假设、所需产物、可能的执行通道以及缺失的决策。在第一批面向用户的问题之前，Metis 必须按意图主动展开仓库/外部研究：explore 映射本地表面，精确的 gpt-5.6-terra researcher 通道收集官方/上游或 OSS 参考证据。研究密集的意图使用更多低成本 researcher，而不是降低 Metis/Momus/Oracle 的判断力。

将访谈作为有界循环运行：

1. 识别每个当前为 UNKNOWN 的清单项，以及每个其答案会实质性改变范围、安全性或验证的 CRITICAL 问题。
2. 将该轮独立问题批量放入单个 Structured Question Surface 调用（questions[] 数组，或在 tmux 外使用编号散文回退）。
3. 收集结构化的 answers[]，然后运行 Gap-fill Pass 1 — answer assimilation：更新证据与假设，并仅当 USER_ANSWERED、ABSORBED_WITH_CITATION 或 INFERRED_FROM_SPEC 时将清单项标记为 YES。
4. 运行 Gap-fill Pass 2 — residual adversarial scan：对照仓库上下文、先前轮次、研究展开证据、框架/行业默认值以及保守的可逆默认值，重新检查每个剩余的 UNKNOWN；以引用/假设吸收非 CRITICAL 缺口，仅保留 CRITICAL 阻塞项。
5. 在第 1 轮之后运行 between-round planning：刷新或复用 <research_fan_out> explore/researcher 证据，重新运行 spec prefill，并仅根据剩余的 CRITICAL 缺口准备第 2 轮。
6. 仅在两轮 gap-fill 和至少两轮已发出问题轮次的门控之后，评估 6 项清单（<Turn_Termination_Rules> 三态）；当全部为 YES 且要么未发出问题，要么第 2 轮已发出并处理完毕时退出。
7. 如果未达到清单清零，或仅处理了第 1 轮，则返回步骤 1 进行下一轮。上限为 5 轮；达到上限时，将剩余的 UNKNOWN 项作为显式 <unresolved_blocker> 条目转交 Oracle。

3. Momus 挑战（有界重试）

使用 prometheus-strict-momus 作为对抗性批评声音。当原生子代理可用时，调用专用 Agent；否则在上下文内运行同一角色，不编辑文件。

Momus 会挑战规格不足的验收标准、不安全的假设、隐藏的破坏性步骤、过宽的范围、缺失的验证、所有权冲突以及 $ultragoal/$team 交接歧义。

有界重试契约：在 §4 中 Oracle 综合之后，对综合后的计划重新调用 Momus，以验证 Oracle 的解决方案没有引入新风险（添加范围却没有匹配的验证、产生依赖循环的通道拆分、与停止条件矛盾的安全强化）。将 Momus → Oracle 重新综合循环最多重复 3 次总计。如果第 3 次循环后仍有阻塞性反对意见，则在最终计划中将其标记为 carry-forward，并继续到 §5。

4. Oracle 综合（两轮：综合 + 自验证）

使用 prometheus-strict-oracle 作为综合发声者。当有原生子 Agent 可用时，调用专用 Agent；否则在上下文中执行同一角色，而不编辑文件。

第 1 轮——综合。 Oracle 产出的最终目标、范围与非目标、已接受的假设、已解决的批评、排序后的步骤或泳道、验证矩阵、回滚/升级条件，以及推荐的 OMX 交接。

第 2 轮——自验证（可机器检查的验收契约）。 Oracle 重新阅读其第 1 轮的输出并断言：

• 验证矩阵中的每一项声明都有明确的证据来源（测试/构建/lint/e2e/文档）。
• 每个步骤都列出其负责人/泳道/执行者；并行泳道之间没有共享文件冲突。
• 停止、回滚和验收标准彼此一致（没有任何验收标准会被同样触发回滚的状态所满足）。
• 没有任何破坏性、需要凭据或外部生产环境的步骤未经授权。
• 交接命令是具体的（可逐字调用）并指向一个存在的工作流（$ultragoal、$team 或 none）。
• 清洁室信用得到保留。

如果任何第 2 轮检查失败，Oracle 必须先循环回第 1 轮修复，然后才能发出计划。第 1 轮 ↔ 第 2 轮循环上限为 3 次；在第 3 次循环失败时，发出计划并将失败的关卡标注为结转项，同时升级给用户。

5. 计划后缺口检查（Metis 重新调用）

在交接之前，对最终确定的 Oracle 计划重新调用 prometheus-strict-metis，只有一个任务：识别仅在计划呈现之后才浮现的歧义——例如，新的泳道分配出现重叠、由停止条件揭示的验证矩阵缺口、与回滚契约相矛盾的验收标准。

如果计划后的 Metis 发现任何阻塞性缺口，则带着新问题返回 §4 第 1 轮。否则继续到 §6。

6. 交接

除非用户明确调用或授权下一个工作流，否则 Prometheus Strict 会停在一个计划上。优先采用以下顺序：

$ultragoal "<Oracle plan summary or .omx/plans/prometheus-strict/<slug>.md>"
$team <N>:executor "execute the approved Ultragoal story in parallel lanes"  # only when warranted

<Tool_Usage>

• 使用只读仓库检查来验证所引用的文件、命令和现有约定。
• 将 Metis 研究扇出视为规划的一部分，而非执行：在非平凡意图的问题生成之前，先派出 explore / 精确的 gpt-5.6-terra researcher 进行证据收集，然后重新预填充并只询问仍然存在的 CRITICAL 缺口。
• 按顺序使用 prometheus-strict-metis、prometheus-strict-momus 和 prometheus-strict-oracle；不要从本技能扇出实现工作。
• 仅当计划就绪后，才使用 $ultragoal 作为推荐的执行交接。
• 仅当并行泳道相互独立且可验证时，才使用 $team。 </Tool_Usage>

状态管理

Prometheus Strict 不拥有长时间运行的运行时循环。如果需要持久化的规划产物，请将最终计划写入 .omx/plans/prometheus-strict/<slug>.md。仅草稿或内联计划可以将产物路径设为 N/A - inline plan only。

不要为此技能创建 hook 状态、Sisyphus 状态或 start-work 兼容状态。

<Final_Checklist>

• 目标结果明确。
• 范围和非目标明确。
• 验收标准可度量。
• Metis 访谈循环仅在所有 answers[] 批次后强制执行两次补缺遍历，并且（如果发出了任何问题轮次）在最少两个已发出问题轮次的门槛之后，才达到清单通过；否则在达到 5 轮上限时，将 UNKNOWN 项作为 <unresolved_blocker> 条目继续传递。
• Momus 反对意见已解决，或作为明确阻塞项继续传递，且最多消耗 3 次 Momus → Oracle 重新综合循环。
• Oracle 计划包含验证矩阵。
• Oracle Pass 2 自验证已完成；每个可机器检查的契约项均通过，或标注为继续传递。
• 计划后 Metis 差距检查未产生阻塞性反对意见（或全部继续传递）。
• 仅在确有需要时，交接才推荐 $ultragoal 和 $team。
• 洁净室署名得到保留。
• 未引入 hook 实现或 Sisyphus/start-work 移植。

</Final_Checklist>

## 输出契约

如果写入持久化计划文件，请将此 markdown 存储于 .omx/plans/prometheus-strict/<slug>.md，并在交接中引用该路径。

## Prometheus Strict Plan

### Target Result
- <one-sentence objective>

### Clarified Requirements (Metis)
- <requirement / acceptance criterion>

### Critique Resolved (Momus)
- <risk or objection> -> <resolution>

### Oracle Execution Plan
1. <sequenced step or lane>

### Verification Matrix
| Claim | Required evidence | Owner/lane |
| --- | --- | --- |
| <claim> | <test/build/lint/e2e/doc evidence> | <owner> |

### Artifact
- Durable plan path: `.omx/plans/prometheus-strict/<slug>.md` or `N/A - inline plan only`

### Handoff
- Recommended next workflow: <$ultragoal / $team / direct execution / none>
- Stop condition: <what proves the plan is ready or why it is blocked>

### Clean-Room Credit
Inspired by OMO Prometheus (`code-yeongyu/oh-my-openagent`), reimplemented from concept under MIT.

失败与升级

当无法安全推断必要答案、下一步具有破坏性或受凭据限制、所需仓库上下文不可用，或用户要求的行为超出非目标范围时，请升级而非继续规划。

原始任务： {{PROMPT}}