interview

/ouroboros:interview

曖昧な依頼を、Seed に必要な目標、制約、受け入れ基準へと整理するソクラテス式インタビューです。

必須のスキル機能

• ask_user：実行中のランタイムの ask_user 機能を使って、人間の判断が必要な質問をします。
• inspect_code：ユーザーに質問する前に、リポジトリ内の正確なファイルを参照して、リポジトリ固有の事実に関する質問に答えます。
• call_mcp：Ouroboros MCP ツールを使って、インタビューの状態を保持し、Seed を生成します。
• orchestrate_subagents：助言を行うレーンと、Seed の準備状況を確認する Acceptance Guard のレーンを実行します。
• run_lateral_review：マイルストーンの切り替わりと、直接回答をまとめる前に、水平思考を行うサブエージェントを呼び出します。
• web_research：インタビューで本当に必要な場合に限り、最新の外部情報を取得します。
• refine_answer：自由記述の回答を転送する前に、構造化した解釈を確認します（Refine ゲート）。
• maintain_ledger：曖昧さ、ゲート、未解決の決定事項をメインセッションで常に確認できるようにします。
• run_closure_gate：MCP が Seed の準備完了を報告していても、Seed の準備状況を確認する Acceptance Guard を実行します。
• restate_goal：目標を言い直し、Seed の生成前に明示的な承認を求めます（Restate ゲート）。

省略できないゲート

• スコープ、制約、または決定事項に関わる自由記述の回答には Refine ゲートを適用します（ステップ 4）。
• メインセッションに、常に確認できる曖昧さの記録を表示します（ステップ 6）。
• MCP の Seed 準備完了（meta.seed_ready=true）は、Seed の準備状況を確認する Acceptance Guard を実行する許可であり、完了を意味するものではありません（ステップ 8）。
• Seed の生成を提案または実行する前に、Restate ゲートを通し、ユーザーから明示的な承認を得ます（ステップ 9）。

サーバーでは、最後の 2 つを required_client_gates 内で seed_ready_acceptance_guard と restate_goal_approved という名前で定義しています。

使用方法

ooo interview [topic]
/ouroboros:interview [topic]

トピックはスキルの引数です。引数がない場合は、ユーザー自身の依頼がトピックになります。すぐにそこから始め、トピックを再度尋ねたり、先に Ouroboros の説明をしたりしないでください。更新はバックグラウンドで確認されます。コンテキストに Ouroboros の更新通知が含まれている場合は、最初の質問の後に ooo update に一度だけ触れてください。

MCP ツールの読み込み（スキーマ遅延への対策）

Ouroboros ツールは遅延読み込みされる場合があり、あるターンで読み込んだスキーマが次のターンにはアンロードされることがあります。各 ouroboros_* の呼び出し直前に、実行中のランタイムのツール検出機能を使ってスキーマを読み込んでください。ouroboros_interview には "+ouroboros interview"、ouroboros_lateral_think には "+ouroboros lateral" を指定します。スキーマが読み込まれていない状態で呼び出すと、「Invalid tool parameters」というエラーが発生します。ツールをすでに呼び出せる場合、検出処理は何も行わず、空の結果が返ることが想定されます。フォールバックは、ツールが実際に存在しない場合に限って使用してください。

ouroboros_interview を呼び出せる場合は、Path A を使用してください。Path B は、Ouroboros MCP サーバーが実際に存在しない場合に限って使用してください。

Path A：MCP モード

MCP は質問を生成し、状態を保持して、曖昧さを評価します。ただし、コードの読み取り、ウェブの閲覧、ツールの呼び出しはできません。メインセッションでコードや調査から答えられることに対応し、人間の判断が必要な目標、受け入れ基準、ビジネスロジック、好みだけをユーザーに尋ねます。ユーザーに代わって決定してはいけません。自動確認は事実に限って使用します。

1. インタビューを開始します。

   Tool: ouroboros_interview
   Arguments:
     initial_context: <user's topic or idea>
     cwd: <current working directory>
     confused_terms: <optional explicit terms the user does not understand>
     references: <optional [{reference_id, label, origin, url?, excerpt?}]>
   

   セッション ID と最初の質問が返されます。confused_terms と references は、アダプターから渡される構造化コンテキストであり、要件ではありません。最初の質問を変更するために使用してはいけません。その後は、用語集による補足は明示的に「意味がわからない」とされた用語だけに限定し、参照情報は対比を尋ねる質問にのみ使用します。語彙の多さから、わからない用語や参照先を推測したり、参照先の URL やファイルを取得したりしてはいけません。後の回答では、ユーザーが新しい参照情報を提示した場合、または用語の意味を尋ねた場合に限って、それらを含めてください。プロダクトに関する決定事項は回答に含めてください。

2. 以下の PATH に沿って各質問を処理します。 まずレスポンスを確認してください。

   • meta.status="parent_question_required" または meta.ask_user_directly=true：失敗ではなく、通常のターンです。レスポンスのテキストに従い、あなた自身がソクラテス式の質問を1つしてください。MCP、プロバイダーの障害、reason_code には決して触れず、ユーザーの回答を last_question にあなたが尋ねた質問と完全に同じ文言で設定して送信してください。
   • meta.question_advisory_request：以下の「質問優先のアドバイザリーファンアウト」を実行します。
   • meta.lateral_review_required=true：以下の「マイルストーンのラテラルレビューのディスパッチ」を実行します。
   • エラーおよび meta.reason == "initial_context_too_large"：失敗時の再試行を参照してください。

   質問優先のアドバイザリーファンアウト：まずインタビューの質問を提示してください。アドバイザリーは人間が回答するための支援です。質問を隠したり、置き換えたり、遅らせたりしてはいけません。各レーンの処理中も質問を表示したままにしてください。

   meta.question_advisory_subagents がある場合、すべてのペイロードを処理する必要があります。各エントリ（title、agent、prompt、context）は、そのまま子エージェントに渡せる作業であり、プロンプトは変更せずに渡してください。散文からプロンプトを再構成してはいけません。meta.question_advisory_host_action に従ってください。spawn_subagents は並列サポートが指定されていることを意味し、dispatch_subagents_if_supported は利用可能であればネイティブの並列ディスパッチを行い、そうでなければ順次処理することを意味し、process_payloads_sequentially は指定された順序で処理することを意味します。スタンプされた dispatch_mode（host_driven、dispatch_mode="host_decides"、sequential）も同じことを示します。ペイロードが作業上の契約であり、ホストアクションが実行方法を選択します。並列ディスパッチの場合は、アクティブなランタイムの orchestrate_subagents 機能を使って、1回のファンアウト処理でペイロードごとに子エージェントを1つ起動してください。すべての結果を待ってから統合してください。

   レーン：code_context（リポジトリ内の事実。meta.code_investigation_request を再利用）、web_context（最新の外部情報が回答に影響する場合のみ）、data_context（測定を実施。「データの測定」を参照）、ambiguity_contrarian（隠れた前提、曖昧な用語、未決定の事項、リスクのあるデフォルト）、answer_simplifier（簡単な選択肢を2～3個、または簡潔な草案を1つ）、architecture_implications（所有権、インターフェース、ロールアウト、システム構成）。簡潔な補助情報として、回答の選択肢を2～3個、推奨する草案を1つ、または短い曖昧さの指摘を作成してください。ユーザーが承認、編集するか、安全な回答の自動確定を明示的に求めるまで、アドバイザリーの出力を ouroboros_interview に渡してはいけません。

   ファンアウト結果の送信（再入）：メタデータに fanout_id（meta.question_advisory_fanout_id、またはラテラルペルソナパネルのもの）が含まれる場合、すべての子エージェントが結果を返した後、ouroboros_submit_fanout_results を呼び出してください。次の値を指定します。

   • session_id：ファンアウトが発行されたセッション。発行元にセッションがあった場合、省略すると拒否されます。
   • fanout_id：スタンプされた ID。
   • correlation_key：スタンプされた result_correlation_key（context.lane_id、context.persona、または code_facts）。ファンアウトに記録されている場合、省略すると拒否されます。
   • results：レーンごとに1つのエントリを指定します。形式は { "key": <correlation value>, "content": <child output> }、または正確に { "key": <lane>, "undispatched": true }（リテラルの true を使用し、content は指定しません）のいずれかです。実行して何も見つからなかったレーンも、その出力を送信してください。まったく起動できなかったレーン（機能がない、子エージェントが終了した、ユーザーがキャンセルした）は undispatched とします。実行していないレーンの出力を捏造してはいけません。不正なエントリがあると、status="invalid_result_entry" と invalid_keys がまとめて返されます。 完全なセットを送信すると、境界が定められたアーティファクトのエンベロープが返されます。contract_id を指定して ouroboros_fetch_artifact を呼び出し、取得した body 内の相関する統合内容をもとに続行してください。ホストにシェルがない場合でも、この MCP フェッチは必須です。不完全なセットの場合は、missing_required_keys を含む status="partial" が返されます。不足しているものだけでなく、手元にあるすべてのレーンを再試行してください。各呼び出しの間で、送信済みの出力は保持されないためです。逐次処理するホストでは、出力を蓄積して、増えたセットを送信します。完了を妨げるのは required: true とマークされたレーンのみです。取得した統合内容をもとに、インタビューを続けてください。

   データの測定：data_context レーンはホストのデータツールを検出し、自ら測定を行い、読み取った集計値を返します。このレーンが実行されるまでは何も確定されず、実行後に何かが実行されることもありません。ユーザーがツールを登録したことは、そのツールの呼び出しへの同意を意味します。出力に測定値が含まれる場合：

   • 数値はユーザーの判断材料として、質問のそばに示してください。回答として扱ってはいけません。ユーザーは通常の [from-user] 経路で回答します。転送する [from-data] の回答はありません。
   • 集計値は、報告されたとおりに、metric と、それが判断材料となる意思決定とともに保持してください。数値の再導出、再スケーリング、結合は行わないでください。
   • 測定値が届くまでにユーザーがすでに質問に回答していた場合、その測定値は破棄してください。それを使って意思決定を再検討してはいけません。根拠は意思決定に役立てるものであり、一度行った意思決定を蒸し返すものではありません。

   data_needed が false の場合、その理由が説明するのはレーンであり、ユーザーのインフラストラクチャではありません。定型文を貼り付けず、自分の言葉で伝えてください。not_a_measurement、question_too_ambiguous_to_measure、answer_would_not_be_an_aggregate の場合は、そのまま次に進んでください。no_data_store_described は、データストアの存在を把握しており、かつレーンにその情報が伝えられていない場合にのみ言及してください。store_described_but_not_callable は、こちらで対処するものであり、ユーザーに伝えるものではありません。ツールが利用可能か確認し、自分で読み取るか、レーンを再ディスパッチしてください。測定値に読み取り専用やコストに関する免責事項を付けてはいけません。その確認を行うものはありません。

   マイルストーンの横断レビューのディスパッチ：meta.lateral_review_required=true（古いレスポンスでは meta.lateral_review_recommended=true のみ）は、インタビューが曖昧さのマイルストーン（initial -> progress、progress -> refined、refined -> ready）を越えたことを意味します。サーバーがこれを通知するのは、セッションごと、マイルストーンごとに最大 1 回です。このターンでは必須の軽量なサブエージェントレビューとして扱い、非表示で実行してください。質問を提示した後、meta.lateral_review_tool_args を指定して ouroboros_lateral_think を呼び出し、そのペルソナのペイロードを助言レーンと同じファンアウトターンでディスパッチします。これについてユーザーに告知してはいけません。そのペルソナは、助言レーンがすでに実行しているものを除いたものだけです。したがって、その結果は別のブロックにせず、同じヘルパー（選択肢または推奨する草案）に組み込み、結果によって推奨回答または次の質問が変わる場合にのみ言及してください。古い助言フィールドしかない場合は、personas=["researcher","contrarian","simplifier"] を使い、セッション、マイルストーン、質問を含む問題のコンテキストと、次のインタビューの振り分け判断を説明する現在のアプローチを設定してください。横断レビューのツールを利用できない場合は、インタビューを続け、レビューを実行できなかったことを伝えてください。横断レビューによって要件が変わったり、それだけでインタビューが完了扱いになったりすることはありません。 メインセッションでの直接回答支援：MCP の質問に自分で回答したり、ユーザーの自由記述を判断にまとめたりする場合、アドバイザリーレーンは横断的なレビューとして機能します。ambiguity_contrarian と answer_simplifier はすべての質問で反対意見を述べるペルソナと簡潔化するペルソナを実行し、architecture_implications はアーキテクトを実行します。その出力から具体的な選択肢を2～3個、または推奨案を1つ作成し、ユーザーに承認、調整、または自動モードへの切り替えを促します。アドバイザリーレーンを伴う質問に対して、再度 ouroboros_lateral_think を呼び出してはいけません。応答にアドバイザリーレーンが含まれていなかった場合（たとえば、自分で質問を書く meta.ask_user_directly=true のターン）に限り、部分的な入力からプロダクト、UX、またはアーキテクチャに関する回答をまとめようとしているなら、その質問に対して最大1回だけ呼び出します。トレードオフ、優先事項、対象外事項、リスク、または成功基準には contrarian、回答によってシステムの構成やオーナーシップが変わる場合は architect、ユーザーが忙しそう、または簡潔な場合は simplifier を使います。同じく、応答しない場合は沈黙を守ります。

   PATH 1：コードに関する回答（現状：スタック、フレームワーク、依存関係、パターン、アーキテクチャ、ファイル構成）。inspect_code を使用します。記述であり、指示ではありません。「プロジェクトは JWT を使用している」は事実ですが、「新機能では JWT を使用すべき」は判断なので、PATH 2 に進みます。

   • PATH 1a：自動確認は、以下の条件をすべて満たす場合に限ります。回答がマニフェストまたは設定ファイル（pyproject.toml、package.json、go.mod、Dockerfile、.env.example、ロックファイル、CI 設定）と完全に一致し、純粋な記述であり、曖昧さがない（候補が1つ）こと。直ちに [from-code][auto-confirmed] を送信し、操作を妨げない注記（ℹ️ 自動確認済み：Python 3.12、FastAPI フレームワーク（pyproject.toml））を表示します。後からユーザーが誤りだと伝えた場合は、訂正を再送します。
   • PATH 1b：コードの確認は、それ以外の場合（パターンからの推測、候補が複数ある、マニフェストに一致するものがない）に使用します。[from-code] を付けて確認パターンに従います。

   PATH 2：人による判断（目標、ビジョン、受け入れ基準、ビジネスロジック、好み、トレードオフ、スコープ、新機能の挙動）：選択肢を提示して ask_user で質問し、[from-user] を付けます。

   PATH 3：コード＋判断（事実はあるものの解釈が必要な場合。例：「orders/ に saga パターンが見られます。payments でも同じパターンを使いますか？」）：まずコードを読み、見つかった内容を質問とともに提示したうえで、質問全体をユーザーに委ねます。[from-user] を付けます。

   PATH 4：調査の中断（サードパーティ API、価格、ライブラリの機能、バージョンの互換性、セキュリティ勧告、コードベースでは回答できない標準）：web_research を使用し、[from-research] を付けて確認パターンに従います。事実であり、判断ではありません。「Stripe のレート制限は100 req/s」は調査事項ですが、「Stripe を使うべき」は PATH 2 です。

   判断に迷ったら、PATH 2 を使用します。

   確認パターン（PATH 1b、PATH 4）：ask_user で「MCP からの質問：<質問>。見つかった内容：<調査結果とその情報源>。正しいですか？」と尋ね、選択肢に はい、正しいです と いいえ、訂正します を提示します。

   • はい、正しいです：簡潔な事実に、該当する PATH のプレフィックスを付けて送信します。Refine ゲートは不要です。
   • いいえ、訂正します、またはユーザーが直接訂正を入力した場合：自由記述で訂正後の回答を集めます（理由、制約、または維持すべきスコープがあれば尋ねます）。Refine ゲートを実行し、[from-user][refined] を付けて送信します。

3. 回答を送信します。

   Tool: ouroboros_interview
   Arguments:
     session_id: <session ID>
     answer: <prefixed answer>
     last_question: <exact question text, required when you rather than MCP asked it (parent handoff, Restate reopen)>
   

   MCP が認識するのは送信したテキストのみなので、推論をラベルにまとめてはいけません。理由、制約、またはスコープを含む自由記述の回答は、Refine ゲートの後、次の複数セクションのペイロードとして送信します。

   [from-user][refined]
   Decision: Stripe Billing.
   
   Reasoning:
   - Subscription is the core business model.
   
   Constraints (user-stated):
   - 30% Korean MAU, KRW required.
   
   Out of scope (user-stated):
   - Refund policy changes, tax-invoice issuance.
   
   Codebase context (main session verified):
   - src/payments/toss_adapter.py is one-shot KRW only.
   

   PATH 1a の事実、承認された確認事項、付随情報のない短い PATH 2 の回答（[from-user] はい）は、1行で構いません。 接頭辞：[from-code]、[from-user]、[from-research]は情報源を示し、[auto-confirmed]はPATH 1aを示します。Refineゲートを通過した場合に限り、[refined]を追加します。MCPでは、refinedの回答を信頼度の高い確かな情報として扱います。refinedの回答でインタビューを明示的に終了する場合は、[closure]マーカーを追加します（[from-user][refined][closure]）。自然言語のフレーズとの一致によって終了を判定してはいけません。

4. Refineゲート（推論、制約、または範囲を含む自由記述の回答）。回答を上記のペイロードに整理してから、ask_userを通じて次のように尋ねます：「MCPに送信する前に、回答を次のように整理しました：。不足している内容や、誤って伝わっている内容はありますか？」選択肢：そのまま送信、制約に追加、対象外に追加、コンテキストを追加、書き直す。

   • そのまま送信以外の選択肢が選ばれた場合は、ラベルから不足しているテキストを推測してはいけません。具体的なテキストを尋ねるフォローアップを1回行い、その内容を反映してから、Refineゲートをもう一度実施します。2回目の回答でも変更が求められた場合は、PATH 2で焦点を絞ったフォローアップを行い、ユーザーがテキストを提示するか、ペイロードを承認するまでMCPの回答を保留します。不完全だとユーザーが指摘したペイロードを転送してはいけません。
   • PATH 1aの事実、承認済みの確認、推論を伴わない短いPATH 2の回答では省略します。修正内容の言い換え（ステップ9）では、どれほど短くても省略してはいけません。

5. 対話リズムガード。 ユーザーから直接の判断を得ずに連続して回答された質問の数を数えます（PATH 1aでの自動確認、および承認済みのPATH 1b／PATH 4の確認）。3回に達したら、コードや調査で回答できる場合でも、次の質問は必ずPATH 2にします。ユーザーが直接回答した場合（PATH 2、PATH 3、または[from-user][refined]として送信された修正内容）は、カウントを0にリセットします。

6. 曖昧さの台帳。 スコープ、制約、出力、検証の各項目を独立したトラックとして明示し、インタビューが一つのサブトピックに偏らないようにします。

7. ユーザーがインタビューを終了する（[from-user][refined][closure]を送信する）か、応答にmeta.seed_ready=trueが含まれるまで、ステップ2～6を繰り返します。

8. シード準備完了の承認ガード。 MCPがシード準備完了を示した場合、完了をそのまま伝えてはいけません。完了を告知したり、ooo seedを提案したりする前に、MCPが確認できていないコード、調査、およびブラウンフィールドのコンテキストを各レーンに与え、orchestrate_subagentsを使って3つのレーンを実行します（ランタイムに並列実行の機能がない場合は、順番に実行します）。各レーンはcontext.lane_idで識別し、以下の役割を担います。

   • closer：seed-closer.mdの基準を適用し、Path Bの役割プロンプトと同じ方法で解決します。この判定がゲートとなります。
   • contrarian：隠れた前提、意味が広すぎる用語、インタビューで見送られた判断を確認します。
   • gap_hunter：不足している要件、列挙されていない制約、未対応のエッジケース、検証不能な受け入れ基準を確認します。

   各レーンはJSONのみを返します。

   • closer：{"lane_id": "closer", "verdict": "seed_ready" | "not_ready", "reason": "...", "blocking_question": "..." | null}
   • contrarian／gap_hunter：{"lane_id": "<lane>", "severity": "high" | "medium" | "low", "finding": "...", "question": "..." | null}。highは、その不足によって実装が実質的に変わる場合に限ります。

   closerの判定がseed_ready以外の場合、またはcontrarian／gap_hunterのいずれかの重大度がhighの場合は、終了できません。その場合はシグナルを上書きして（「MCPはシード準備完了と示していますが、があるため、まだ承認できません。」）、不足点を簡潔に説明し、最も影響の大きい質問を1つだけPATH 2またはPATH 3で尋ねます。

9. 言い換えゲート（Seed 準備完了の受け入れガードを通過した後）。合意した目標を一文で言い換え、ask_user を通じて次のように尋ねます：「目標：＜一文で言い換えた内容＞。この一文だけを読んだ人は、あなたが思い描いている結果にたどり着けるでしょうか？」選択肢：Yes, generate seed、Adjust wording、Missing scope。

   • Yes, generate seed：ooo seed を提案します。
   • Adjust wording / Missing scope：置き換える文言、または不足している条件や境界について尋ねます。これは実際のインタビュー修正です。Refine ゲートを実行し、Decision には修正後の目標文を一字一句そのまま設定し、Reasoning にはユーザーの修正内容を言い換えずに記載し、ユーザーが提示した制約、対象外項目、確認済みのコードベースのコンテキストも含めます。last_question には、実際に尋ねた Restate の追加質問をそのまま設定し、[from-user][refined] として送信します。ハンドラーは last_question がない場合、再開要求を拒否します。ステップ 7 に戻り、MCP に状態を更新させてからステップ 8 を再実行します。修正前の状態から ooo seed に進んではいけません。
   • その後、修正後の文で Restate ゲートをもう一度尋ねます。2 回を超えて繰り返してはいけません。それでも認識が一致しない場合は、目標文を無理に確定させず、PATH 2 の具体的な質問をしてください。

失敗時の再試行

• is_error=true かつ meta.recoverable=true：ユーザーに再試行することを伝え、session_id を指定して ouroboros_interview を呼び出し、再開します（状態は保持されます。再試行は最大 2 回）。それでも失敗する場合は、直接インタビューモードに切り替えることを伝え、中断した箇所から Path B を続けます。
• meta.reason == "initial_context_too_large"（is_error=false）：このテキストはインタビューの質問ではなく、あなたへの指示です。ask_user に回してはいけません。元の initial_context（目標、制約、成功基準）を meta.max_chars の範囲内で要約し、session_id とともに answer として再送信します。次の応答に実際の最初の質問が含まれます。

Path B：フォールバック（MCP サーバーなし）

1. socratic-interviewer プロンプトを読み、その役割を担います。オーバーライドが設定されている場合は $OUROBOROS_AGENTS_DIR/socratic-interviewer.md、それ以外の場合は run_shell で出力されるインストール済みパッケージ内のコピーを使用します。

   uvx --isolated --python '>=3.12' --from ouroboros-ai python -c "import importlib.resources as r, sys; print(r.files('ouroboros.agents').joinpath(sys.argv[1]).read_text(encoding='utf-8'))" socratic-interviewer.md
   

   それ以外の場合は、ソースチェックアウト内の src/ouroboros/agents/socratic-interviewer.md を使用します。

2. inspect_code を使って設定ファイル（pyproject.toml、package.json、go.mod など）を事前にスキャンし、自由回答形式で探るのではなく、「X を確認しました。Y と想定してよいでしょうか？」のような確認形式の質問をします。

3. 提案する回答を添えて、ask_user を通じて各質問をします。必要に応じて inspect_code と web_research を使います。

4. 曖昧さの記録を維持します。独立した論点を追跡し、数ラウンドごとに未解決の論点を再確認します。また、1 つのサブトピックに元の依頼を押しのけさせないでください。

5. 自由記述の回答には Refine ゲートを、終了前には Seed 準備完了の受け入れガードを、ooo seed の提案前には Restate ゲートを適用します。MCP の状態がない場合は、Restate による修正をローカルの記録と目標文に反映し、ガードをローカルで再実行してから、Restate ゲートをもう一度尋ねます。

6. 結果は会話内にのみ存在し、保持されません。

RFC #1392 状態ブレッドクラムのフッター

最終応答の末尾は、◆ <現在の状態> → next: <推奨アクション> という形式の行をちょうど 1 行にします。ouroboros_session_status が利用可能な場合は、ライブセッションの状態から状態を判断し、そうでない場合はこのスキルの実際の結果から判断します。Step N of M という直線的なフッターは使用しないでください。次の手順が実際の選択肢である場合は、2～3 個の選択肢を列挙します。