deep-interview

Deep Interview は、計画や実装の前に行う意図優先のソクラテス式明確化ループです。why(ユーザーがなぜ変更を望むのか)、どこまで行うべきか、何をスコープ外にすべきか、OMX が確認なしで決めてよいことは何か、といった点について的を絞った質問をすることで、曖昧なアイデアを実行可能な仕様に変換します。

<Use_When>

• リクエストが広範、曖昧、または具体的な受け入れ基準が欠けている
• ユーザーが "deep interview"、"interview me"、"ask me everything"、"don't assume"、"ouroboros" と言う
• 要件が不十分なために、実装が意図とずれることを避けたい
• ralplan、autopilot、ultragoal、team に引き渡す前に要件成果物が必要 </Use_When>

<Do_Not_Use_When>

• リクエストに具体的なファイル/シンボルの対象と明確な受け入れ基準がすでにある
• ユーザーが計画/インタビューを省略し、すぐに実行するよう明示的に求めている
• ユーザーが軽量なブレインストーミングのみを求めている(代わりに plan を使用)
• 完全な PRD/計画がすでに存在し、実行を開始すべき段階である </Do_Not_Use_When>

<Why_This_Exists> 実行品質は通常、実装の詳細が不足していることよりも、意図の明確さによって制限されます。単一の拡張パスでは、ユーザーがなぜ変更を望むのか、スコープをどこで止めるべきか、どのトレードオフが許容できないか、どの決定にまだユーザーの承認が必要かを見落としがちです。このワークフローは、ソクラテス式の問いかけと定量的な曖昧さスコアリングを組み合わせることで、オーケストレーションモードが明示的でテスト可能、かつ意図に沿った仕様から開始できるようにします。 </Why_This_Exists>

<Depth_Profiles>

• Quick (--quick): 高速な PRD 前パス。目標しきい値 <= 0.30、最大ラウンド数 5
• Standard (--standard、デフォルト): 完全な要件インタビュー。目標しきい値 <= 0.20、最大ラウンド数 12
• Deep (--deep): 厳密性を重視した探索。目標しきい値 <= 0.15、最大ラウンド数 20
• Autoresearch (--autoresearch): インタビューの厳密さは Standard と同じだが、$autoresearch のミッション準備と .omx/specs/ 成果物の引き渡しに特化

プロファイルの max rounds は厳格な上限であり、目標ではありません。ラウンド番号に達するためだけに続けないでください。追加のソクラテス式の厳密さは、プロファイルや設定が変わらない限り、有効なしきい値を上書きしません。

フラグが指定されていない場合は Standard を使用します。

<Mode_Flags>

• --autoresearch: インタビューを $autoresearch 引き渡し用の autoresearch-intake モードに切り替えます。このモードでは、インタビューは検証可能な調査ミッションに収束し、正規の成果物を .omx/specs/ 配下に書き出し、下流のスキル受け入れに対して明示的な「さらに改善する」と「起動」の境界を維持する必要があります。 </Mode_Flags> </Depth_Profiles> <Execution_Policy>
• 1ラウンドにつき質問は1つだけにしてください（複数のインタビューラウンドを1つの questions[] フォームにまとめないでください）
• 実装の詳細より前に、意図と境界について尋ねてください
• 上記のステージ優先ルールを適用したうえで、各ラウンドで最も明確さが不足している次元を対象にしてください
• ユーザーの各回答は、次に進む前に検証すべき主張として扱ってください。次の質問では、通常、根拠や例を求める、隠れた前提を明らかにする、トレードオフや境界を迫る、または根本原因と表面的な症状を切り分けるなど、いずれかを行ってください
• 現在の回答がまだ曖昧な場合は、網羅性のためだけに新しい明確さの次元へ移らないでください。一段深く掘り下げる、一つの前提を明確にする、または一つの境界を絞り込むまで、同じテーマにとどまってください
• 結晶化する前に、以前の回答を、より深く、前提に焦点を当てた、またはトレードオフに焦点を当てたフォローアップで再検討する、明示的な圧力確認を少なくとも一度行ってください
• 内部の仕組みについてユーザーに尋ねる前に、explore でコードベースの事実を収集してください
• omx explore は非推奨です。単純な読み取り専用のブラウンフィールド事実収集には、通常のリポジトリ調査ツールやサブエージェントを使用してください。omx sparkshell は、明示的にシェルで取得できる読み取り専用の根拠が必要な場合にのみ使用し、曖昧な場合やシェルだけでは完結しない調査には、より高機能な通常のパスを使用してください
• 最初のインタビュー質問の前には、必ず事前のコンテキスト収集を実行してください
• ブラウンフィールド作業の場合、事前確認には、ユーザーへの質問の前に、ドキュメントとコンテキストの裏付けを含めてください。具体的には、適用される AGENTS.md ファイル、README・入門ドキュメント、関連する docs/ の契約・計画・ADR、既存の .omx/context/ スナップショット、そして存在する場合は CONTEXT.md や CONTEXT-MAP.md などプロジェクトローカルの用語集・コンテキストファイルを確認してください
• 既存のリポジトリの用語は、権威ではなく証拠として扱ってください。ユーザーが曖昧、多義的、または矛盾する用語を使う場合は、該当するドキュメントやコードの具体的な表現を示し、実装前にどの意味を優先すべきかを尋ねてください
• 発見可能な場合は、ユーザーのヒアリングによる現在の動作に関する主張を、コードまたは文書化された契約と照合してください。ドキュメントとコードが食い違う場合は、両方の出典を示す確認の質問をしてください。黙ってどちらかを選ばないでください
• 関係、境界、または引き継ぎの振る舞いが不明確な場合は、シナリオベースのエッジケース検証を使用してください。曖昧な境界を試す具体的なシナリオを一つ作り、期待される結果について焦点を絞った質問を一つしてください
• 永続的なドキュメント、用語集、ADR、またはメモリの更新はオプトインであり、公開しても安全な内容に限ります。deep-interview は引き継ぎの要約で such 更新を推奨することはできますが、ユーザーが明示的にスコープ内として選択しない限り、インタビューの記録から公開ドキュメントを自動作成したり、書き出したりしてはいけません
• 初期コンテキストが過大である場合、またはプロンプトの予算を超える場合は、生のペイロードをインタビューのプロンプトに貼り付けたり転送したりしないでください。まず、プロンプトに安全な初期コンテキストの要約を依頼し、記録してください
• 過大な初期コンテキストの要約ゲートは阻止的です。曖昧さの採点、成果物の結晶化、または後続の実行への引き継ぎの前に、簡潔な要約を待ってください
• 要約には、目標、制約、成功基準、非目標、意思決定の境界、および完全な元資料への参照を保持し、後続の利用者がプロンプトに安全でありながら忠実なコンテキストを受け取れるようにしてください
• 保持する履歴は要約または削減して、プロンプトペイロード全体を安全な予算内に収めてください。最新かつ最も重要な回答を優先し、生の過大なコンテキストが現在の質問を圧迫しないようにしてください
• ユーザーの負担を減らすため、最も効果の高い未解決の質問のみをしてください。エージェントが直接発見できるコードベースの事実を、ユーザーに尋ねないでください
• ブラウンフィールド作業では、「Y で X を見つけました。これは同じパターンに従うべきでしょうか？」のような、根拠に基づく確認の質問を優先してください
• Ouroboros のスタイルに従い、判断より事実を先に扱ってください。ユーザーに向けたインタビューラウンドを提示する前に、必要な情報が発見可能な事実か、確認が必要な事実か、または人間の判断事項かを分類してください。インタビューは判断のために人間に対して行うものであり、エージェントが確認できる事実のためのものではありません
• 未解決の曖昧さが、現在の外部のベストプラクティス、公式・上流のガイダンス、標準、またはバージョンに応じた動作に依存する場合は、要件を結晶化する前、または計画・実行に引き継ぐ前に、$best-practice-research を限定的な根拠の収集ラッパーとして使用してください
• 以下のトランスクリプト・仕様ラベルのみを使用してください。これらを omx question の source 値として使用したり、ユーザー向けの deep-interview 質問で実行時の source: "deep-interview" 契約を置き換えたりしないでください:
  • [from-code][auto-confirmed] — マニフェストや設定ファイル、または直接のソースコードの根拠から得られる、正確で信頼性の高いコードベースの事実。それに規範的な内容は付随しません。
  • [from-code] — 有用ではあるものの推論によるもの、パターンに基づくもの、または信頼性が低い・中程度のコードベースの発見事項。そのため、確定した事実として扱う前に、確認形式のユーザー向けラウンドが必要です。
  • [from-research] — API の上限、互換性、公開ドキュメントなど、外部から得られた事実。事実のみであり、判断は含みません。
  • [from-user] — 目標、好み、ビジネスロジック、スコープ、非目標、受け入れ基準、トレードオフ、および判断を伴うあらゆる解釈。
• [from-code][auto-confirmed] やその他のユーザー以外の事実発見は、インタビューラウンドではなく、コンテキストやトランスクリプトの更新として扱ってください。エージェントが安全に確定できる事実について、omx question を呼び出さないでください、保留中の deep-interview 質問の義務を作らないでください、そしてユーザー向けのラウンド番号を増やさないでください
• 記述的な事実のみを自動確認してください。ある発見が、新機能がどう動くべきか、どのパターンに従うべきか、どのトレードオフを受け入れるべきか、またはスコープの内外に何を置くべきかを示唆する場合は、コードや調査による事実が利用可能であっても、判断を伴う質問全体を [from-user] としてユーザーに回してください
• tmux 上で接続された Codex CLI では、deep-interview は、すべてのインタビューラウンドにおいて、必須の OMX 所有の構造化質問経路として omx question を使用します
• tmux 上で接続された Bash やツール経路から omx question を呼び出す場合は、コマンドの前に OMX_QUESTION_RETURN_PANE=$TMUX_PANE（または具体的な %pane の値）を付けて、リーダーペインへの戻り先を維持してください
• バックグラウンドのターミナルで omx question を起動した場合は、直ちにそのバックグラウンドターミナルの終了を待ち、JSON の回答を読み取ってから、曖昧さを採点したり、別のラウンドを行ったり、引き継いだりしてください
• answers[] を omx question の主要な成功契約として扱ってください。単一のインタビューラウンドでは answers[0].answer を読み取ってください。必要な場合にのみ、互換性のための代替として、従来のトップレベルの answer を使用してください
• 現在の実行環境が tmux の外にあり、omx question を表示できない場合は、利用可能であればネイティブの構造化質問ツールを使用してください。利用できない場合は、簡潔な平文の質問を一つだけして、回答を待ってください
• 各回答の後に曖昧さを再採点し、進捗を透明に示してください
• 曖昧さが有効なプロファイルのしきい値以下になったら、通常の質問を止めてください。実用的な締めくくりの監査を実行してください。準備ゲートを満たしていれば結晶化・引き継ぎを行い、満たしていなければ、指定されたゲートを満たすために必要な最後の締めくくりの質問だけをしてください
• max_rounds は停止上限として扱い、さらにラウンドが必要であることの根拠として扱わないでください
• 加重された曖昧さのしきい値を満たしていても、Non-goals または Decision Boundaries が未解決のままであれば、結晶化や引き継ぎをしないでください
• 実行への引き継ぎは、ユーザーが警告付きで続行することを明示的に選ばない限り、曖昧さがしきい値を上回っている間は行わないでください
• 早期終了は通常の成功経路ではなく、安全弁として扱ってください
• 再開時の安全性のためのモード状態の永続化は、CLI やプログラムによる単一書き込み権限（src/state/operations.ts に基づく omx state write/read --input '<json>' --json）を通じてのみ行ってください。MCP 状態サーバーは読み取り専用の投影であり、2 つ目の書き込み元になってはいけません </Execution_Policy>

Phase 0: 事前コンテキスト取り込み

1. {{ARGUMENTS}} を解析し、短いタスクのスラッグを導出します。
2. .omx/context/{slug}-*.md から、最新の関連コンテキストスナップショットの読み込みを試みます。
3. 提供された初期コンテキストまたは読み込んだスナップショットが、プロンプトに安全に使うには大きすぎないかを確認します。大きすぎる場合、最初のインタビューラウンドでは、曖昧さのスコアリングや後続のハンドオフへ進む代わりに、プロンプトに安全な簡潔な要約を求める必要があります。
4. スナップショットが存在しない場合は、次の項目を含む最小限のコンテキストスナップショットを作成します:
   • タスクの記述
   • 期待される成果
   • 明示された解決策（ユーザーが求めたこと）
   • 推定される意図の仮説（なぜそれを求めているのとみられるか）
   • 既知の事実・証拠
   • 制約
   • 不明点・未解決の質問
   • 決定境界の不明点
   • 想定されるコードベース上の接点
   • 確認した関連リポジトリのドキュメント・ルール・コンテキスト
   • 見つかった用語や、ドキュメントとコードの矛盾
   • プロンプトに安全な初期コンテキスト要約のステータス（not_needed、needed、recorded のいずれか）
5. ブラウンフィールドのタスクでは、ユーザーに向けた最初のラウンドの前に、該当するドキュメント・ルールの範囲を確認します。広範なスキャンよりも、正確で近接したソースを優先します:
   • 触れるパスに適用される、管理用の AGENTS.md ファイルおよびテンプレート・ランタイムの指示面
   • README・はじめに系ドキュメントおよび docs/ 配下の関連ドキュメント（特にコントラクト、計画、ADR に類する記録、ワークフロー文書）
   • スラッグに関連する既存の .omx/context/ スナップショット、.omx/specs/、および計画成果物
   • CONTEXT.md、CONTEXT-MAP.md などのプロジェクトローカルな用語集・コンテキストファイル、またはコンテキスト固有のドキュメント（存在する場合）
6. スナップショットを .omx/context/{slug}-{timestamp}.md（UTC の YYYYMMDDTHHMMSSZ）に保存し、モードの状態からそれを参照します。

Phase 1: 初期化

1. {{ARGUMENTS}} と深度プロファイル（--quick|--standard|--deep）を解析します。
2. プロジェクトのコンテキストを検出します:
   • explore を実行して、ブラウンフィールド（既存コードベースが対象）かグリーンフィールドかを分類します。
   • ブラウンフィールドの場合は、質問する前に関連するコードベースのコンテキストを収集します。
3. omx state write --input '{"mode":"deep-interview","active":true}' --json で状態を初期化します:

{
  "active": true,
  "current_phase": "deep-interview",
  "state": {
    "interview_id": "<uuid>",
    "profile": "quick|standard|deep",
    "type": "greenfield|brownfield",
    "initial_idea": "<user input>",
    "rounds": [],
    "current_ambiguity": 1.0,
    "threshold": 0.3,
    "max_rounds": 5,
    "challenge_modes_used": [],
    "codebase_context": null,
    "current_stage": "intent-first",
    "current_focus": "intent",
    "context_snapshot_path": ".omx/context/<slug>-<timestamp>.md"
  }
}

4. プロファイル、閾値、現在の曖昧さを示してキックオフを告知します。

Phase 2: ソクラテス式インタビューのループ

曖昧さが <= threshold に達するか、プレッシャーパスが完了し、準備完了のゲートが明示されるか、ユーザーが警告付きで終了するか、または最大ラウンド数に達するまで繰り返します。これは停止条件です。閾値を下回った場合は、新たな通常のインタビュー分岐を開始してはいけません。

2a) 次の質問を生成する

初期コンテキストが過大で、まだプロンプトに安全な要約が記録されていない場合、次の質問は要約のみを求めるものでなければなりません。要約への回答が記録されるまでは、曖昧さをスコア化せず、準備状況ゲートも実行せず、$ultragoal、$ralplan、$autopilot、$team へのハンドオフも行わないでください。

以下を使用します:

• 元のアイデア
• これまでの Q&A ラウンド
• 現在の各ディメンションのスコア
• ブラウンフィールドのコンテキスト（ある場合）
• ドキュメント/コンテキストの根拠メモ（既存の用語、準拠すべきルール、ドキュメントとコードの不一致を含む）
• 有効化されたチャレンジモードの注入（フェーズ3）

最もスコアの低いディメンションを対象としつつ、ステージの優先順位を守ります:

• ステージ1 — 意図優先: 意図、成果、スコープ、非ゴール、判断境界
• ステージ2 — 実現可能性: 制約、成功基準
• ステージ3 — ブラウンフィールドの根拠付け: コンテキストの明確さ（ブラウンフィールドのみ）

各回答の後のフォローアップ・プレッシャー・ラダー:

1. 直前の主張の背後にある具体例、反例、または証拠のシグナルを求める
2. その主張を真にしている前提、依存関係、または信念を探る
3. 境界またはトレードオフを強制する: 明示的に何をしないか、延期するか、拒否するか
4. リポジトリで文書化された用語と現在のコードの振る舞いに照らして、曖昧または矛盾する用語に異議を唱える
5. 関係性やハンドオフが曖昧なままの場合は、具体的なシナリオや エッジケース を一つ使って境界を検証する
6. 回答がなお症状を述べているだけなら、先に進む前に本質/根本原因へと問い直す

レバレッジが最も高い場合は、複数ラウンドにわたって同じテーマに留まることを優先します。圧力のない広がりは進展ではありません。

独立した曖昧さのトラックにわたって Breadth Ledger（幅の台帳） を維持します: スコープ、制約、成果物、検証、ブラウンフィールドとの統合、およびユーザーが言及したその他の成果物トラック。この台帳はガードであり、必須のローテーションルールではありません。現在のテーマを検証しきるまでその深掘りを続け、実行に影響する未解決の重要なトラックが残っている場合にのみ視野を広げてください。

ブラウンフィールドのインタビューでは Docs/Terminology Ledger（ドキュメント/用語の台帳） を維持します:

• 確認したリポジトリのドキュメント/ルール/コンテキストソース（パス参照付き）
• リポジトリで既に使われている正規の用語、および避けるべき用語や明確化すべき用語
• ドキュメントまたは現在のコードの振る舞いと矛盾するユーザーの用語
• 実装前に人間の判断が必要なドキュメントとコードの不一致
• 提案は安全だが自動適用はしない、任意の永続ドキュメントの後続作業

詳細なディメンション:

• Intent Clarity（意図の明確さ） — ユーザーがなぜこれを望むのか
• Outcome Clarity（成果の明確さ） — どのような最終状態を望むのか
• Scope Clarity（スコープの明確さ） — 変更がどこまで及ぶべきか
• Constraint Clarity（制約の明確さ） — 満たさなければならない技術的または事業上の制限
• Success Criteria Clarity（成功基準の明確さ） — 完了をどのように判定するか
• Context Clarity（コンテキストの明確さ） — 既存コードベースの理解（ブラウンフィールドのみ）

Non-goals（非ゴール）と Decision Boundaries（判断境界）は必須の準備状況ゲートです。早い段階で質問し、明示されるまで繰り返し確認してください。

2b) 質問する

すべてのインタビューラウンドで、そのサーフェスに適した構造化質問の経路を使用してください。アタッチされた tmux セッションでは、OMX が管理する omx question による構造化質問を使用します（これは deep-interview に必須の、構造化質問の同等手段であり、必須の AskUserQuestion 相当の手段です）。tmux の外では、利用可能な場合はネイティブの構造化入力を使用してください。利用できない場合は、簡潔な平文の質問を 1 つだけ行い、回答を待ちます。提示内容は次のとおりです:

Round {n} | Target: {weakest_dimension} | Ambiguity: {score}%

{question}

インタビューラウンドにおける omx question ペイロードのガイダンス:

• Deep-interview はソクラテス式です。一度に 1 つの焦点を絞ったラウンドで質問してください。omx question は他のワークフロー向けにバッチ形式をサポートしていますが、複数のインタビューラウンドをまとめるために一括の questions[] を使用しないでください。
• 生の multi_select フラグを手作業で記述するのではなく、正規の type 値を使用してください。type: "single-answerable" は一つの経路を決める判断のデフォルトです。type: "multi-answerable" は、制限された複数選択ラウンドの正規の形式です。ランタイムは multi_select を type と整合した状態に保ちます。
• 正確に 1 つの回答が次の分岐を決めるべき場合、選択肢が相互排他的である場合、または複数の回答を選ぶと判断の境界があいまいになる場合は、single-answerable を使用してください。典型的な例: 引き継ぎレーンの選択、主要な障害モードの選択、競合する複数の解釈のうちどれが正しいかの確認です。
• 複数の選択肢が同時に真でありうり、1 つのラウンドで共存する制約、非目標、リスク、または受け入れチェックの制限された集合を取得する必要がある場合は、multi-answerable を使用してください。典型的な例: スコープ外の項目をすべて選ぶ、満たすべきすべての成功指標を選ぶ、同時に適用されるすべてのデプロイ制約を選ぶ、です。
• 1 つの選択肢を選ぶと、他の選択肢を区別するための追加質問がすぐに必要になる場合は、今は single-answerable のラウンドを優先し、追加質問は次に行ってください。過負荷の複数選択プロンプトの中に、分岐するインタビューツリーを隠さないでください。
• インタビューの選択肢は、範囲を限定し具体的に保ってください。有効な回答がすでにわかっている場合は allow_other: false を設定してください。allow_other: true を残すのは、事前に列挙できないユーザー提供のオプションが本当に 1 つ必要な場合だけにしてください。
• 回答は、主要な answers[] 配列から構造的に読み取ってください。通常の単一ラウンドのインタビュー応答では、answers[0].answer を正とします。トップレベルの answer フィールドは、単一質問の旧式の投影/フォールバックに過ぎません。
• single-answerable の場合、answers[0].answer の value フィールドに、選択された値のメタデータとともに、決定的な 1 つの選択が含まれていることを期待してください。multi-answerable の場合、answers[0].answer 内の selected-values フィールドを、選ばれたすべての制約/非目標の正となる情報源として扱い、その完全な集合をトランスクリプトと仕様に保持してください。単一質問の旧式の投影では、これは次と同等です: multi-answerable の場合、answer.selected_values を正となる情報源として扱ってください。

正規の制限付き単一選択ペイロード:

{
  "question": "Which execution lane should own this once the interview is complete?",
  "type": "single-answerable",
  "options": [
    {
      "label": "Plan first",
      "value": "ralplan",
      "description": "Need architecture and test-shape review before execution"
    },
    {
      "label": "Execute directly",
      "value": "autopilot",
      "description": "Requirements are already explicit enough for planning plus execution"
    },
    {
      "label": "Refine further",
      "value": "refine",
      "description": "Clarification is still needed before any handoff"
    }
  ],
  "allow_other": false,
  "other_label": "Other",
  "source": "deep-interview"
}

正規の制限付き複数選択ペイロード:

{
  "question": "Which non-goals must stay out of scope for the first pass?",
  "type": "multi-answerable",
  "options": [
    {
      "label": "No UI redesign",
      "value": "no-ui-redesign",
      "description": "Keep layout and styling unchanged"
    },
    {
      "label": "No new dependencies",
      "value": "no-new-dependencies",
      "description": "Work within the existing toolchain"
    },
    {
      "label": "No API contract changes",
      "value": "no-api-contract-changes",
      "description": "Preserve external request and response shapes"
    }
  ],
  "allow_other": false,
  "other_label": "Other",
  "source": "deep-interview"
}

正規の回答形式のリマインダー:

{
  "answer": {
    "kind": "option",
    "value": "ralplan",
    "selected_labels": ["Plan first"],
    "selected_values": ["ralplan"]
  }
}

{
  "answer": {
    "kind": "multi",
    "value": ["no-new-dependencies", "no-api-contract-changes"],
    "selected_labels": ["No new dependencies", "No API contract changes"],
    "selected_values": ["no-new-dependencies", "no-api-contract-changes"]
  }
}

2c) あいまいさのスコアリング

加重された各次元を [0.0, 1.0] でスコアリングし、根拠と不足点を示します。

Greenfield: ambiguity = 1 - (intent × 0.30 + outcome × 0.25 + scope × 0.20 + constraints × 0.15 + success × 0.10)

Brownfield: ambiguity = 1 - (intent × 0.25 + outcome × 0.20 + scope × 0.20 + constraints × 0.15 + success × 0.10 + context × 0.10)

準備完了ゲート:

• Non-goals が明示されていること
• Decision Boundaries が明示されていること
• 圧力確認（pressure pass）が完了していること。少なくとも1つの以前の回答を、根拠、前提、またはトレードオフに関するフォローアップによって再検討している必要があります
• 実務上のクロージャー監査に合格していること。別の質問によって実行内容が実質的に変わるのであり、単に文言を磨くことや、狭い例外的ケースを追うことではない必要があります
• いずれかのゲートが未解決である場合、または圧力確認が未完了の場合は、未解決のゲートを明示し、実行に実質的な影響を与える最終クロージャー質問を1つだけ行ってしきい値未満のまま続行します。
• 低いあいまいさスコアは、クロージャーを監査する許可であり、無期限に掘り下げ続ける許可ではありません。残りの不確実性が実装を変えないのであれば、新しい分岐を開くのではなく、仕様を確定させます。
• あいまいさが <= 0.10 の場合、ユーザーへの追加質問は最終クロージャー質問としてのみ許可されます。それ以外の場合は直ちに仕様を確定させます。

2d) 進捗の報告

加重内訳の表、準備完了ゲートの状態（Non-goals、Decision Boundaries）、および次の重点次元を表示します。

2e) 状態の永続化

ラウンドの結果と更新されたスコアを omx state write --input '<json>' --json で追記します。{mode}-state.json を直接書き込まないでください。また、読み取り専用の MCP state projection を書き込み用に使用しないでください。

2f) ラウンドの制御

• 最初の明示的な前提確認と、それに続く持続的なフォローアップの1回が行われるまで、早期終了を提示しないでください。
• Dialectic Rhythm Guard（対話リズムガード）を適用してください。ユーザー以外からの事実発見および確認型の回答（[from-code][auto-confirmed]、[from-code]、または [from-research]）が連続して発生している回数を追跡します。ユーザー以外または確認型の回答が3回連続した後の、次の重要なユーザー向けラウンドでは、クロージャー監査によってインタビューが確定可能な状態であると判断されない限り、人による直接的な判断（[from-user]）を求める必要があります。
• 4ラウンド目以降: リスク警告を伴う明示的な早期終了を許可します。
• プロファイルの中間点（プロファイルに応じて例えば3/6/10ラウンド目）でソフト警告を出します。
• プロファイルの max_rounds でハードキャップを設けます。このキャップを、望ましいインタビューの長さや割り当て量として扱ってはいけません。

Phase 3: 挑戦モード（前提の検証テスト）

該当する場合は各モードを1回ずつ使用します。これらは通常のエスカレーション手段であり、まれな救済策ではありません。

• Contrarian（反論者）（2ラウンド目以降、または回答が未検証の前提に依拠している場合は即座に）: 中核となる前提に異議を唱えます
• Terminologist（用語統一者）（ブラウンフィールドで、主要な用語があいまい、多義的、またはリポジトリのドキュメント/コードと矛盾する場合は常に）: 実装前に、既存のプロジェクトの言語に照らして正規の意味を確定させます
• Simplifier（簡素化者）（4ラウンド目以降、またはスコープが結果の明確さよりも速く拡大している場合）: 最小限の実行可能スコープを探ります
• Ontologist（本質探究者）（5ラウンド目以降かつあいまいさ > 0.25、またはユーザーが症状を説明し続けている場合）: 本質レベルでの再定義を求めます

重複を防ぐため、使用したモードを状態に記録してください。

Phase 4: アーティファクトの確定

しきい値に到達したとき（またはユーザーが警告付きで終了した場合、もしくはハードキャップに達した場合）:

1. インタビューの記録の要約を次の場所に書き出します:
   • .omx/interviews/{slug}-{timestamp}.md （ralph の PRD 互換性のために保持）
2. 実行可能な仕様書を次の場所に書き出します:
   • .omx/specs/deep-interview-{slug}.md

仕様書には次の内容を含めます:

• メタデータ（プロファイル、ラウンド数、最終的な曖昧さ、しきい値、コンテキストの種類）
• コンテキストスナップショットの参照先またはパス（ralplan/team での再利用のため）
• 大きすぎるコンテキストが提供された場合のプロンプトに安全な初期コンテキストの要約、および元の完全なソースドキュメントへの参照
• 明確さの内訳の表
• 意図（ユーザーがこれを望む理由）
• 期待される成果
• スコープ内
• スコープ外／非目標
• 決定の境界（OMX が確認なしに決定してよい事項）
• 制約
• テスト可能な受け入れ基準
• 明らかになった前提と解決策
• プレッシャーパスの結果（どの回答を再検討し、何が変わったか）
• リポジトリに基づく確認質問について、ブラウンフィールドの根拠と推論の注記
• 調査したリポジトリのドキュメント／ルール／コンテキストを含むドキュメント・用語台帳、用語の衝突、およびドキュメントとコードの不一致に関する決定
• スコープや受け入れ基準を実質的に形作ったシナリオ／エッジケースのプレッシャー調査結果
• 任意の永続的なドキュメント化の推奨事項（オプトインであることと公開しても安全であることを明記）。生のプライベートなトランスクリプトのダンプは含めないこと
• 技術コンテキストの調査結果
• トランスクリプトの全文または要約版

Autoresearch の特化

明確化されたタスクが具体的に $autoresearch に関するものである場合、または --autoresearch オプションでスキルが呼び出された場合は、明確化のステップを省略せずに、インタビューをドメイン固有の内容に保ち、スキルが利用できるアーティファクトを出力します。

• 受け入れる初期入力: topic、evaluator、keep-policy、slug、既存のミッション草案テキスト、および過去の評価者の例／テンプレート
• インタビューの必須フォーカス: ミッションの明確さ、評価者の準備状況、keep ポリシー、slug／セッション名、および草案を今すぐ起動できる状態か、さらに改善すべきか
• 正規のアーティファクトパス: .omx/specs/deep-interview-autoresearch-{slug}.md
• 起動アーティファクトのバンドル: .omx/specs/autoresearch-{slug}/mission.md、.omx/specs/autoresearch-{slug}/sandbox.md、および .omx/specs/autoresearch-{slug}/result.json
• 起動アーティファクトのディレクトリ: .omx/specs/autoresearch-{slug}/
• 必須のアーティファクトセクション:
  • Mission Draft
  • Evaluator Draft
  • Launch Readiness
  • Seed Inputs
  • Confirmation Bridge
• .omx/specs/autoresearch-{slug}/ 配下の必須の起動アーティファクト:
  • mission.md
  • sandbox.md
  • result.json
• 起動準備の規則: 評価者コマンドに <...>、TODO、TBD、REPLACE_ME、CHANGEME、your-command-here などのプレースホルダーマーカーが含まれている間は、草案を 起動準備完了ではない とマークします
• 構造化された結果の契約: result.json は草案およびミッション／サンドboxのアーティファクトを指し、確定した topic、evaluatorCommand、keepPolicy、slug、launchReady、blockedReasons フィールドを保持して、$autoresearch が直接利用できるようにします
• 確認のブリッジ: アーティファクト生成後、少なくとも refine further（さらに改善する）と launch（起動する）を提示します。CLI による直接の起動や、デタッチ／分割された tmux での起動は行わず、明示的な確認を得た後にのみ $autoresearch に引き継ぎます
• 引き継ぎの規則: 後続の実行では、このアーティファクトで明確化されたミッションの意図、評価者への期待、決定の境界、および起動準備の状態を維持する必要があります。草案のレビュー手順を飛ばしてはいけません

Phase 5: 実行ブリッジ

アーティファクト生成後、明示的な引き継ぎ契約を用いて実行オプションを提示します。deep-interview の仕様書を現在の要件の正とみなし、引き継ぎの間も、意図、非目標、決定の境界、受け入れ基準、ドキュメントと用語の根拠、および残存リスクに関する警告を維持します。

任意の実行契約の基盤

Autopilot/deep-interview のハンドオフで stride 契約が明示的に要求される場合は、散文ではなく構造化データとして出力してください。これは広範さの推論機能ではなく、検証の基盤です。タスクの長さ、フェーズラベル、スナップショット、自由記述の文言から stride を推論しないでください。

Autopilot の状態配下の正規の保存場所:

{
  "handoff_artifacts": {
    "deep_interview": {
      "execution_contract_required": true,
      "execution_contract": {
        "version": 1,
        "execution_stride": "task",
        "source": "deep-interview",
        "selected_by": "user",
        "allow_task_shrink": true,
        "completion_unit": "One focused task",
        "stop_condition": "Stop after that task is implemented and verified",
        "acceptance_coverage_scope": "task",
        "shrink_policy": "allowed"
      }
    }
  }
}

Stride の意味:

• task: 保守的で小さなステップの実行。allow_task_shrink:true、acceptance_coverage_scope:"task"、shrink_policy:"allowed"。
• deliverable: 停止する前に指定された成果物を完了させる。allow_task_shrink:false、acceptance_coverage_scope:"deliverable"、shrink_policy:"ask_before_shrink"。
• milestone: ブロックされない限り、承認された大きなマイルストーンを完了させる。allow_task_shrink:false、acceptance_coverage_scope:"milestone"、shrink_policy:"deny_unless_blocked"。

execution_contract_required:true は、選択された後続ワークフローがこの明示的な stride/停止条件ガードを必要とする場合にのみ設定してください。新しい成果物では、上記の正規の snake_case スキーマを handoff_artifacts.deep_interview の下に記述しなければなりません。ランタイムのリーダーは、レガシーの camelCase フィールド/マーカーのエイリアスや、直接または入れ子の execution_contract の位置を、互換性のための入力としてのみ受け入れることができます。execution_contract_required が存在しない場合、または false の場合、後続の Autopilot の互換性動作は変更されません。

Goal モードのフォローアップ

明確化された仕様に合う場合は、既存の $ultragoal、$ralplan、$autopilot、$team のハンドオフオプションを削除せずに、以下のプロダクト向けの提案を含めてください:

• $ultragoal — 実装や一般的な目標指向のフォローアップ仕様を、順次完了追跡を伴う永続的な Codex/OMX の goal に変換する場合のデフォルトの goal モードのフォローアップ。
• $autoresearch — 明確化されたコンテキストが研究プロジェクトである場合に使用します。研究課題、参考文献・文献の収集、評価者によって裏付けられた分析、または教授/批評家スタイルの成果物が該当します。
• $performance-goal — 明確化されたコンテキストが、速度、レイテンシ、スループット、メモリ、ベンチマーク、評価者の基準で測定可能な最適化またはパフォーマンスプロジェクトである場合に使用します。

$ultragoal は Ralph の目標追跡を置き換えるため、デフォルトの永続的な goal モードのフォローアップとして推奨してください。調整された並列実装には $team を残してください。

1. $ultragoal（デフォルトの永続的実行フォローアップ）

• 入力アーティファクト: .omx/specs/deep-interview-{slug}.md（トレーサビリティのために、必要に応じて transcript/context snapshot を併せて使用）
• 呼び出し: $ultragoal create-goals --brief-file <spec-path> の後に、アクティブな実行レーンで $ultragoal complete-goals
• コンシューマーの動作: 明確化された仕様を永続的な goal モードの作業に変換します。intent、non-goals、decision boundaries、acceptance criteria、docs/terminology grounding、scenario-pressure findings、residual-risk warnings を、拘束力のあるストーリー制約として維持してください。
• スキップ / 充足済みのステージ: 要件インタビュー、曖昧さの明確化、doc/context のプリフライト、初期の intent-boundary の抽出
• 期待される出力: .omx/ultragoal/brief.md、.omx/ultragoal/goals.json、.omx/ultragoal/ledger.jsonl、実装の証跡、検証の証跡、および最終的なクリーンアップ/レビューゲートの証跡
• 最適な場面: 明確化された仕様が実行可能な状態にあるとき、またはユーザーが次のステップとして永続的な goal 追跡を明示的に望む場合
• 次の推奨ステップ: Ultragoal の完了ループを実行します。並列レーンが妥当な場合にのみ、アクティブな Ultragoal ストーリー内で $team を起動してください。

2. $ralplan（アーキテクチャ/テスト形状のレビューがまだ必要な場合に推奨）

• 入力アーティファクト: .omx/specs/deep-interview-{slug}.md（トレーサビリティのため、必要に応じてトランスクリプト/コンテキストスナップショットを添付）
• 呼び出し方法: $ralplan <spec-path>
• コンシューマーの動作: deep-interview の仕様書を要件の信頼できる情報源（source of truth）として扱います。デフォルトではインタビューを繰り返さず、明確化された意図と境界を中心にアーキテクチャと実現可能性を精緻化します。
• スキップ / 既に充足されているステージ: 要件の発見、曖昧さの明確化、初期段階での意図境界の抽出
• 期待される出力: .omx/plans/ 配下の正式な計画アーティファクト。特に prd-*.md と test-spec-*.md
• 最適な場面: 要件がインタビューを打ち切れるほど明確である一方、アーキテクチャの検証やコンセンサス形成による計画立案が依然として望ましい場合
• 次の推奨ステップ: 承認された計画アーティファクトを用いて、デフォルトの持続的なゴールモードのフォローアップとして $ultragoal を使用します（並列レーンが必要な場合は $team と併用可能）。リサーチの検証には $autoresearch、計測可能な最適化には $performance-goal を選択します。

3. $autopilot

• 入力アーティファクト: .omx/specs/deep-interview-{slug}.md
• 呼び出し方法: $autopilot <spec-path>
• コンシューマーの動作: deep-interview の仕様書を明確化された実行ブリーフとして使用します。意図、非目標、決定境界、受け入れ基準は、計画と実行のための拘束力のあるコンテキストとして維持します。
• スキップ / 既に充足されているステージ: 初期の要件発見と曖昧さの低減
• 期待される出力: autopilot が生成する計画/実行の進捗、QA の証跡、検証アーティファクト
• 最適な場面: 明確化された仕様書が、追加のコンセンサスゲートなしに直接計画と実行へ進めるだけの十分な強度を持つ場合
• 次の推奨ステップ: autopilot の実行/QA/検証フローを継続します。調整作業の負荷が高い実行が必要になった場合は、リーダーが管理する $ultragoal の台帳のもとで $team を優先します。

4. $team

• 入力アーティファクト: .omx/specs/deep-interview-{slug}.md
• 呼び出し方法: $team <spec-path>
• コンシューマーの動作: 仕様書を、協調的な並列作業のための共有実行コンテキストとして扱います。明確化された意図、非目標、決定境界、受け入れ基準は、共通のレーン制約として維持します。
• スキップ / 既に充足されているステージ: 要件の明確化と初期段階の曖昧さの低減
• 期待される出力: 共有仕様に対する協調的なマルチエージェント実行。該当する場合は、既にアクティブな Ultragoal の台帳における最終検証の証跡とチェックポイントを含みます。
• 最適な場面: タスクが大規模、マルチレーン、またはブロッカーの影響を受けやすく、単一の持続的ループではなく協調的な並列実行を正当化するほどの場合
• 次の推奨ステップ: 協調実行フェーズが終了したら、チームの検証パスに従います。該当する場合は、既にアクティブな $ultragoal の台帳にチェックポイントを記録します。検証のみを目的として、別の実行ループを開始しないでください。

5. さらに精緻化する

• 入力アーティファクト: 既存のトランスクリプト、コンテキストスナップショット、現在の仕様書の草案
• 呼び出し方法: インタビューのループを継続する
• コンシューマーの動作: 残っている最も影響の大きい不確実性を解消するために、質問を再開します
• スキップ / 既に充足されているステージ: 既に取得済みのコンテキスト以外はなし
• 期待される出力: 境界がより明確で、未解決の前提が少なく、曖昧さの低い仕様書
• 最適な場面: 残存する曖昧さがなお高すぎる場合、ユーザーがより高い明確性を求める場合、または閾値超過/早期終了の警告により、安全に先へ進むにはリスクが大きすぎることが示されている場合
• 次の推奨ステップ: 仕様書が十分に明確化されたら、上記いずれかの実行への引き継ぎ契約に戻ります。

残存リスクのルール: インタビューが早期終了、ハードキャップによる完了、または閾値超過の警告付き続行によって終了した場合は、下流のスキルが部分的にしか明確化されていないブリーフを引き継いだことを把握できるよう、その残存リスクの状態を引き継ぎ時に明示的に保持してください。 IMPORTANT: Deep-interview は要件定義モードです。ハンドオフ時には、上記の契約に従って選択したスキルを呼び出してください。deep-interview 内で直接実装しないでください。

<Tool_Usage>

• コードベースの事実収集には explore を使用してください
• attached tmux renderer が利用可能な場合、インタビューの各ラウンドで OMX ネイティブの構造化ユーザー入力ツールとして omx question を使用してください
• attached-tmux の Bash/ツール経路からは、明示的な %pane 返却先がすでに分かっている場合を除き、OMX_QUESTION_RETURN_PANE=$TMUX_PANE omx question ... として呼び出してください
• 現在のランタイムが tmux の外にあり omx question を描画できない場合は、利用可能であればネイティブの構造化入力を使用してください。利用できない場合は、簡潔な平文の質問を 1 つだけ行い、回答を待ってください
• omx question が JSON を返した後は、answers[0].answer / answers[] を優先してください。古い形式のレコードに対してのみ、レガシーの answer をフォールバックとして使用してください
• 再開可能なモードの状態には、唯一の書き込み担当である状態操作経路を通じて omx state write/read --input '<json>' --json を使用してください。MCP state サーバーは読み取り専用であり、書き込みのフォールバックにはなりません
• 必須の omx question ラウンドを実行できない場合は、ブロッカーを active: false と current_phase: "blocked" を持つ終端状態として保存してください。active: true で終端のブロック状態を書き込まないでください
• コンテキストのスナップショットは .omx/context/ 配下で読み書きしてください
• プリフライト時に、該当するリポジトリのドキュメント・ルール・コンテキストを読み込んでください。永続的なドキュメント、用語集、ADR、メモリの更新は、ユーザーが明示的に同意し、内容が公開しても安全な場合に限って書き込んでください
• スコアリングやハンドオフの前に、大きすぎるコンテキストの要約ゲートが「不要・保留中・充足済み」のいずれであるかを記録してください
• インタビューの記録と仕様の成果物は .omx/interviews/ および .omx/specs/ に保存してください </Tool_Usage>

<Escalation_And_Stop_Conditions>

• ユーザーが stop/cancel/abort と言った場合 -> 状態を保存して停止してください
• 曖昧さが 3 ラウンドにわたって停滞した場合（±0.05）-> Ontologist モードを 1 回強制してください
• 最大ラウンド数に達した場合 -> 残存リスクの明示的な警告を付けて進めてください
• すべての次元が 0.9 以上の場合 -> 最大ラウンド数に達する前でも早期の結晶化を許可してください </Escalation_And_Stop_Conditions>

<Final_Checklist>

• プリフライトのコンテキストスナップショットが .omx/context/{slug}-{timestamp}.md に存在する
• 大きすぎる初期コンテキストがある場合、曖昧さのスコアリングや後続のハンドオフの前に、プロンプトに安全な要約が記録されている
• 毎ラウンドの曖昧さスコアが表示されている
• 実装の詳細より前に、意図優先のステージ順序が使われている
• 有効なステージ内で、最も弱い次元への重点化が使われている
• 結晶化の前に、少なくとも 1 回は明示的な前提の確認が行われている
• 少なくとも 1 回は、以前の回答を深掘りする持続的なフォローアップ / プレッシャーのパスが行われている
• 該当する場合、チャレンジモードが閾値で発動している
• 記録が .omx/interviews/{slug}-{timestamp}.md に書き込まれている
• 仕様が .omx/specs/deep-interview-{slug}.md に書き込まれている
• ブラウンフィールドの質問では、該当する場合に根拠に基づく確認が使われている
• ブラウンフィールドのプリフライトで、ユーザーへの質問の前に該当するリポジトリのドキュメント・ルール・コンテキストを調査している
• 該当する場合、曖昧または矛盾した用語がリポジトリの言語や現在のコードの振る舞いに照らして検証されている
• 境界の曖昧さが実装に大きく影響する場合、シナリオベースのエッジケースの掘り下げが使われている
• 永続的なドキュメント/ADR/メモリの更新を行う場合は、明示的に同意され、公開しても安全である
• ハンドオフの選択肢（$ultragoal、$ralplan、$autopilot、$team）が提示されており、該当する場合はコンテキストに応じたゴールモードの提案（$autoresearch、$performance-goal）も提示されている
• このモードでは直接の実装を行っていない </Final_Checklist>

## 推奨設定（任意）

Deep-interview は、次の順序で最初に存在する設定ソースからランタイムのデフォルト値を読み込みます。

1. リポジトリローカルの .omx/config.toml
2. リポジトリルートの omx.toml
3. ユーザーグローバルの ~/.omx/config.toml

このセクションは現時点では deep-interview 専用のランタイム上書き機構であり、Codex の config.toml や .omx-config.json によるモデル/環境変数のルーティングを一般的に置き換えるものではありません。 設定ファイルに形式エラーがある場合は、フェイルソフトとして無視され、組み込みのデフォルト値で $deep-interview の起動を続行します。 明示的な --quick、--standard、--deep の起動フラグは defaultProfile より優先されます。

[omx.deepInterview]
defaultProfile = "standard"
quickThreshold = 0.30
standardThreshold = 0.20
deepThreshold = 0.15
quickMaxRounds = 5
standardMaxRounds = 12
deepMaxRounds = 20
enableChallengeModes = true

再開

中断された場合は、$deep-interview を再実行してください。omx state read --input '{"mode":"deep-interview"}' --json を使って、永続化されたモードの状態から再開します。

正規の Autopilot エントリーパイプライン

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

• Autopilot は、この独立した deep-interview の明確化ゲートから開始します。$plan --interview で代用してはなりません。
• ステージ 1（deep-interview）: あいまいさの解消と、実行可能な要件成果物の作成
• ステージ 2（ralplan）: 実現可能性、アーキテクチャ、合意ゲート
• ステージ 3（ultragoal）: 永続的な実行、検証、完了の記録