prometheus-strict

Prometheus Strict

OMO の Prometheus という高レベルなコンセプトのみに着想を得た、クリーンルーム方式の OMX 計画ワークフローです。このスキルは OMO の実装、プロンプト、文言、制御フロー、ランタイムコードを一切コピーしていません。このリポジトリの MIT ライセンスのスキル規約に従い、そのアイデアを再実装したものです。

クレジット: OMO Prometheus（code-yeongyu/oh-my-openagent）からコンセプトに着想を得て、MIT ライセンスのもとで再実装しました。

Prometheus Strict は、あいまいさが依然としてリスクになる場合に、実行前に厳密な計画を作成します。計画の立案では 3 つの役割を分けています。Metis は要件を明確化し、Momus は前提と検証の不足を検証し、Oracle は引き継ぎ可能な OMX ネイティブの計画を統合します。

出力は $ultragoal 向けの計画専用の成果物であり、独立したレーンを分ける正当な理由がある場合は $team 向けにもなります。永続的な成果物が役立つ場合は、最終計画を .omx/plans/prometheus-strict/ に保存するか、保存を依頼してください。

<Use_When>

• 浅い計画だと誤った作業につながりかねないほど、重要なタスクである場合。
• 要件は部分的にわかっているものの、受け入れ基準、境界、リスク、または検証が不完全な場合。
• ユーザーが実行前に厳密なインタビューを希望している場合。
• 将来の $ultragoal のストーリーに、永続的なスコープ、テスト、引き継ぎの順序が必要な場合。
• チーム分割が必要になる可能性があるものの、レーンをまだ安全に割り当てられない場合。 </Use_When>

<Do_Not_Use_When>

• ユーザーが明確で低リスクな変更の即時実装を求めている場合。通常の executor のパスを使用してください。
• タスクがリポジトリの検索や説明だけの場合。必要に応じて explore/analyze を使用してください。
• コード変更後に敵対的な実行 QA が必要な場合。$ultraqa を使用してください。
• ユーザーがフックの動作、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 の文言、ソースコード、プロンプト、ランタイムの動作、制御フローをコピーしたり模倣したりしないでください。
• 非目標を明示しておいてください。フックは実装しません。Sisyphus/start-work の移植は行いません。外部本番環境での自動アクションは実行しません。
• 回答によってスコープ、安全性、または検証が大きく変わる場合は、影響の大きい質問をまとめて一括で行ってください。1 問ずつ尋ねるのは、次の質問が前の回答に依存する連鎖的な質問の場合に限ってください。
• 安全な前提を利用できる場合は、それを明示したうえで作業を続けてください。
• パス、テスト、引き継ぎコマンドを具体的にするために、必要に応じてリポジトリを読んでください。
• Metis による計画中は、タスクが些末である場合、引用された仕様が自己完結している場合、またはキャッシュされた根拠がすでに同じ対象を扱っている場合を除き、重要度が些末でないすべての意図について、ユーザーに質問する前に事前調査の並列展開を実行してください。リポジトリの事実には explore を使用し、外部ドキュメントや OSS の参照には、正確な低コストの gpt-5.6-terra の researcher レーンを使用してください。Prometheus Strict は、ラウンドごとに最大 2 explore + 4 researcher のエージェントを展開してもよいものとします。これにより、Metis/Momus/Oracle はより強い判断の役割を保ちつつ、引用に焦点を当てた小型の調査エージェントを増やして網羅性を確保します。
• $team を推奨するのは、Oracle が独立していて、範囲が限定され、検証可能なレーンを特定した場合に限ってください。 </Execution_Policy>

構造化された質問の経路

Metis/Momus/Oracle からユーザーへの質問はすべて、実行環境に適した構造化質問の経路を通す必要があります。平文での質問は既定ではなく、最後の手段です。

• attached-tmux の OMX ランタイムでは、OMX が管理する構造化質問の経路として omx question を使用します（これは Prometheus Strict における AskUserQuestion に相当します）。attached-tmux の Bash/ツール経路からは、リーダーペインへの戻り先を維持するために、コマンドの前に OMX_QUESTION_RETURN_PANE=$TMUX_PANE（または具体的な %pane の値）を付けてください。
• 独立した影響の大きい質問は、1 回の questions[] 配列呼び出しにまとめてください: スコープ、制約、非目標、成果物、安全上の境界、受け入れ基準は通常互いに独立しているため、ユーザーが 1 つのパネルで一括回答できるよう、必ず 1 つの構造化フォームにまとめる必要があります。1 問ずつ尋ねるのは、次の質問が前の回答に依存する依存関係のある質問連鎖の場合に限ってください。
• 明確化ルールの確認、追加の質問ラウンドの実施、または引き継ぎの前に、omx question の JSON 回答を待ってください。answers[] / answers[i].answer を優先し、従来のトップレベル answer は互換性のための代替手段としてのみ使用してください。answers[] の各バッチの後、別の質問や引き継ぎを行う前に、少なくとも 2 回のギャップ埋めパスを実行してください。パス 1 では、ユーザーの回答をチェックリストに反映します。パス 2 では、リポジトリのコンテキスト、以前のターン、<research_fan_out> による調査結果、保守的な既定値を再確認し、CRITICAL ではない残りのギャップを吸収します。
• 最低 2 回の質問ラウンドを発行する必要があります。Metis が一度でもユーザー向けの質問ラウンドを発行した場合、<turn_aborted> / 敵対的な状況、または 5 ラウンド目の上限によって強制終了される場合を除き、ラウンド 1 の後に引き継ぎを行ってはいけません。引き継ぎは、ラウンド 2 が発行され、処理された後にのみ許可されます。質問を一切発行しなかった場合に、チェックリストが完了した状態で即座に引き継ぐことは引き続き有効です。
• ラウンド間の計画では、根拠を積極的に活用してください。ラウンド 1 の回答と 2 回のギャップ埋めパスの後、<research_fan_out> の explore/researcher による根拠を更新するか再利用し、スペックの事前入力を再実行したうえで、ラウンド 2 は残っている CRITICAL なギャップのみに基づいて作成してください。
• tmux の外では、利用可能な場合はネイティブの構造化入力ツールを使用してください。
• どちらの構造化経路も表示できない場合（tmux 外の Codex CLI、パイプ実行、CI など）は、そのラウンドの独立した質問を番号付きの平文ブロック（Q1: ... Q2: ... Q3: ...）として列挙し、1 回のユーザーターンですべての回答を待ってください。質問を別々のやり取りに分割しないでください。
• 明確化の基準に達していない場合は、複数の質問ラウンドが想定されています。各ラウンドは 1 つのバッチ化されたフォーム（またはその平文の代替）であり、複数のフォームに分割してはいけません。

チェックリストによるクリアランス

インタビューの終了は、主観的な「これで十分そう」という判断ではなく、決定論的なチェックリストによるクリアランスに基づきます。6項目のチェックリストがすべてYESになった時点で、Metisのインタビューループを終了します。項目は、目的／スコープのIN＋OUT／受け入れ条件／テスト戦略／引き継ぎ先／未解決のCRITICALなしです。各項目は、<Turn_Termination_Rules>で定義されている3状態に基づいて評価します。

インタビューのラウンド数は、長引くのを防ぐため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のターンは、以下のいずれか1つだけで必ず終了します。要約だけで終えることや、「もう終わったと思います」と締めくくることは禁止されています。

6項目のチェックリストは、目的／スコープのIN＋OUT／受け入れ条件／テスト戦略／引き継ぎ先／未解決のCRITICALなしです。チェックリスト項目がYESとなるのは、USER_ANSWERED ∪ ABSORBED_WITH_CITATION ∪ INFERRED_FROM_SPECの場合です。UNKNOWN（回答なし、引用なし、仕様からの推定なし）の場合のみNOとして扱います。

• (a) omx questionの一括質問：<gap_triage>と<self_review>を通過したCRITICALな質問が1つ以上ある場合に使用します。一括質問を1ラウンドとして扱い、続行するにはanswers[]を待ちます。
• (b) 明示的な引き継ぎ：6項目のチェックリストがすべてYESの場合に使用します。クリアランス後にMetisからMomusへ、レビュー後にMomusからOracleへ、Pass 2の統合後にOracleからユーザーへ引き継ぐか、<unresolved_blocker>として持ち越します。
• (c) ブロッカーによる停止：<hostility_detection>でサブタイプhostility_exitを伴う敵対的な応答／<turn_aborted>が検出された場合、または次のアクションが破壊的、認証情報を要する、外部本番環境に関わるもので、安全な既定値を設定できない場合に使用します。

エッジケース：

1. 質問はないがチェックリストが完了している場合 → オプション(b)の明示的な引き継ぎを使用します。空のomx questionフォームは出力しないでください。
2. チェックリストが未完了のまま5ラウンドの上限に達した場合 → 残っているUNKNOWN項目を注記して、最後の質問を一括で出すオプション(a)、またはUNKNOWN項目を<unresolved_blocker>エントリーとしてOracleに持ち越すオプション(b)を使用します。
3. 敵対的な応答／<turn_aborted>の場合 → 怒り、罵倒、または中断されたターンにはhostility_exitを用いるオプション(c)、投げやりな委任（알아서／「自分で決めて」）には、ギャップを吸収済みと注記してオプション(b)を使用します。 </Turn_Termination_Rules>

### 1. 受け付けと安全上の制約

目標とする結果、既知の制約、成果物、検証の想定、停止条件を言い換えて確認します。このターンが計画のみを対象とするのか、ユーザーが後続の実行も依頼しているのかを確認します。

プロンプトに、破壊的な判断、認証情報を要する判断、外部本番環境に関わる判断、またはスコープを大幅に変更する判断が含まれている場合は、ユーザーの明示的な確認を得るまで保留します。それ以外の場合は、計画ループを続行します。

2. Metis インタビュー（反復的、チェックリスト解消）

インタビュー担当には prometheus-strict-metis を使用します。ネイティブのサブエージェントが利用可能な場合は専用エージェントを呼び出します。利用できない場合は、ファイルを編集せずに同じロールをコンテキスト内で実行します。

Metis は、成功基準、非目標、根拠と仮定の区別、必要な成果物、想定される実行レーン、不足している判断事項を明らかにします。ユーザーに向けた最初の質問バッチの前に、Metis は各インテントについてリポジトリおよび外部のリサーチを積極的に展開しなければなりません。explore はローカルの対象領域をマッピングし、正確な gpt-5.6-terra の researcher レーンが公式・上流または OSS 参照の根拠を収集します。リサーチ負荷の高いインテントでは、Metis/Momus/Oracle の判断を下げるのではなく、低コストの researcher をより多く使用します。

インタビューは有界なループとして実行します。

1. 現在 UNKNOWN であるすべてのチェックリスト項目と、その回答によって範囲、安全性、または検証が実質的に変わるすべての CRITICAL な質問を特定します。
2. そのラウンドの独立した質問を、1 回の Structured Question Surface 呼び出し（questions[] 配列、または tmux 外での番号付き散文のフォールバック）にまとめます。
3. 構造化された answers[] を収集し、Gap-fill Pass 1 — 回答の取り込み を実行します。根拠と仮定を更新し、USER_ANSWERED、ABSORBED_WITH_CITATION、または INFERRED_FROM_SPEC の場合にのみチェックリスト項目を YES とします。
4. Gap-fill Pass 2 — 残存する敵対的スキャン を実行します。残りの各 UNKNOWN を、リポジトリのコンテキスト、過去のターン、リサーチ展開の根拠、フレームワークや業界の標準的な既定値、そして保守的で可逆な既定値に照らして再確認します。CRITICAL でないギャップは引用や仮定として取り込み、CRITICAL なブロッカーのみを残します。
5. Round 1 の後に ラウンド間の計画 を実行します。<research_fan_out> の explore/researcher の根拠を更新するか再利用し、spec のプリフィルを再実行して、残存する CRITICAL ギャップのみから Round 2 を準備します。
6. 両方の gap-fill パスと、発行された質問ラウンドの最低 2 回という条件を満たした後にのみ、6 項目のチェックリスト（<Turn_Termination_Rules> の三値）を評価します。すべてが YES で、かつ質問が発行されなかったか、Round 2 が発行されて処理済みであれば終了します。
7. チェックリスト解消に至らない場合、または Round 1 のみが処理済みの場合は、ステップ 1 に戻り次のラウンドを実行します。上限は 5 ラウンドです。上限に達した場合は、残りの UNKNOWN 項目を明示的な <unresolved_blocker> エントリとして Oracle に引き継ぎます。

3. Momus による検証（有界な再試行）

敵対的な批評担当には prometheus-strict-momus を使用します。ネイティブのサブエージェントが利用可能な場合は専用エージェントを呼び出します。利用できない場合は、ファイルを編集せずに同じロールをコンテキスト内で実行します。

Momus は、不十分な受け入れ基準、安全でない仮定、隠れた破壊的ステップ、過度に広いスコープ、検証の欠落、担当の衝突、および $ultragoal/$team の引き継ぎにおける曖昧さに異議を唱えます。

有界な再試行の規約: Oracle が §4 で統合した後、Oracle の解決策によって新たなリスクが生じていないことを確認するため、統合された計画に対して Momus を再度呼び出します（対応する検証を伴わないスコープの追加、依存関係のサイクルを生むレーンの分割、停止条件と矛盾する安全性の強化など）。Momus → Oracle の再統合サイクルは合計 3 回まで 繰り返します。3 回目のサイクル後も阻止的な異議が残っている場合は、それらを最終計画において持ち越し事項としてマークし、§5 に進みます。

4. Oracle による統合（2段階：統合＋自己検証）

統合の担い手として prometheus-strict-oracle を使用します。ネイティブのサブエージェントが利用可能な場合は専用エージェントを呼び出し、そうでなければファイルを編集せずに、同じ役割をコンテキスト内で実行します。

Pass 1 — 統合。 Oracle は、最終的な目的、スコープと非目標、受け入れられた前提、解決済みの批評、順序付けられたステップまたはレーン、検証マトリクス、ロールバック／エスカレーションの条件、推奨される OMX への引き継ぎを生成します。

Pass 2 — 自己検証（機械で検査可能な受け入れ契約）。 Oracle は自身の Pass 1 の出力を読み直し、次の項目を検証します。

• 検証マトリクス内のすべての主張に、明示的な証拠の出典（テスト／ビルド／lint／e2e／ドキュメント）があること。
• すべてのステップに担当者／レーン／実行者が記載されていること。並列レーン間で共有ファイルの競合がないこと。
• 停止、ロールバック、受け入れ基準が相互に整合していること（ロールバックを引き起こす状態によって満たされる受け入れ基準が存在しないこと）。
• 破壊的な、認証情報が必要な、または外部の本番環境に影響するステップに、未承認のものがないこと。
• 引き継ぎコマンドが具体的で（そのまま呼び出せ）、既存のワークフロー（$ultragoal、$team、または none）を指していること。
• クリーンルーム方式によるクレジットが保持されていること。

Pass 2 のチェックがいずれか一つでも失敗した場合、Oracle は計画を出力する前に必ず Pass 1 に戻って修正しなければなりません（MUST）。Pass 1 ↔ Pass 2 のサイクルは 3 回を上限とします。3 回目のサイクルで失敗した場合は、失敗したゲストを繰り越し（carried-forward）として注記したうえで計画を出力し、ユーザーにエスカレーションします。

5. 計画後のギャップチェック（Metis の再呼び出し）

引き継ぎの前に、確定した Oracle の計画に対して prometheus-strict-metis を再度呼び出します。課題は一つだけです。計画が描画された後にのみ表面化した曖昧さを特定することです。例としては、重複する新しいレーン割り当て、停止条件によって明らかになった検証マトリクスの欠落、ロールバック契約と矛盾する受け入れ基準などがあります。

計画後の Metis で引き継ぎを阻害するギャップが見つかった場合は、新しい問いを携えて §4 の Pass 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 による調査の分岐（fan-out）は、実行ではなく計画の一部として扱ってください。非自明な意図については、質問を生成する前に explore および正確な gpt-5.6-terra の researcher を使って証拠を収集し、その後に再度前提を整理し、残存する CRITICAL なギャップについてのみ質問してください。
• prometheus-strict-metis、prometheus-strict-momus、prometheus-strict-oracle を順番に使用してください。このスキルから実装作業を分岐（fan-out）させないでください。
• $ultragoal は、計画が準備できた後の推奨される実行への引き継ぎとしてのみ使用してください。
• $team は、並列レーンが独立していて検証可能な場合にのみ使用してください。 </Tool_Usage>

状態管理

Prometheus Strict は長時間実行されるランタイムループを保持しません。永続的な計画成果物が必要な場合は、最終計画を .omx/plans/prometheus-strict/<slug>.md に書き出してください。ドラフトのみの計画またはインラインの計画では、成果物のパスを N/A - inline plan only に設定できます。

このスキルでは、フック状態、Sisyphus 状態、start-work 互換状態を作成しないでください。

<Final_Checklist>

• 目標とする結果が明示されている。
• スコープと非ゴールが明示されている。
• 受け入れ基準が測定可能である。
• Metis インタビューループは、answers[] の各バッチの後に必須の 2 回のギャップ埋めパスを完了し、かつ質問ラウンドが 1 回でも発行された場合は発行済み質問ラウンドの最小 2 回というゲートを満たした後にのみチェックリストのクリアに到達している。そうでない場合は、5 ラウンドの上限に到達し、UNKNOWN の項目が <unresolved_blocker> エントリとして引き継がれている。
• Momus の異議は解決されているか、明示的なブロッカーとして引き継がれている。Momus → Oracle の再統合サイクルは最大 3 回までしか消費されていない。
• Oracle の計画に検証マトリクスが含まれている。
• Oracle の Pass 2 自己検証が完了しており、機械的に検査可能なすべての契約項目が合格しているか、引き継ぎとして注記されている。
• 計画後の Metis ギャップチェックで、ブロッキングな異議が出ていない（またはすべて引き継がれている）。
• 引き渡しでは、必要な場合にのみ $ultragoal と $team を推奨している。
• クリーンルームのクレジットが保持されている。
• フックの実装や Sisyphus/start-work の移植を導入していない。 </Final_Checklist>

## 出力コントラクト

永続的な計画ファイルを書き出す場合は、このマークダウンを .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}}