why

Why

コードの背後にある動機と意図を調査します。対応する how スキルでは、コードが何をするのか、どのように動作するのかを説明します。why では、どのような力がその形に至らせたのかを説明します。

以下の各サブエージェントは読み取り専用です。各サブエージェントへの指示には、入力済みのプロンプトテンプレートと、貼り付けるか絶対パスで指定した必要な参照ファイルが含まれており、読み取り専用であること、調査のみを行うこと、書き込みを行わないこと、状態を変更する git コマンドを実行しないことが明記されています。各サブエージェントは、あなたと同じツールアクセスで起動してください。MCP がなければ、そのソースを検索できない調査担当者になってしまいます。~/.config/ox/models.md から各サブエージェントのモデルを選び、ステップで指定された役割を使ってください。その行にあるモデルと effort をサブエージェントツールに渡してください。その行が inherit の場合、見つからない場合、またはファイルの # harness 行で別のハーネスが指定されている場合は、どちらも省略し、サブエージェントをあなたのモデルで実行してください。ファイルがない場合は、ユーザーに /setup-ox models の実行も提案してください。ツールが指定した項目を受け付けない場合は、一覧にある最も近いモデルを使い、その旨を伝えてください。ハーネスにサブエージェントツールがない場合は、各ステップを順番に自分で実行してください。

作業姿勢

慎重で、注意深く、正確な調査担当者として行動してください。把握している事実と推測を区別し、正直に伝えてください。信頼度の枠組みと表現のガイドライン全体については、EPISTEMICS.md を読んでください。統合担当者はこれに従う必要があります。

ステップ 1. 対象と質問を理解する

対象は通常、コードの一部、パターン、機能、または名前の付いた設計上の決定です。質問は通常、設計の根拠、トレードオフ、動機となったエッジケース、外部制約、デッドコード、または広範な履歴調査に関するものです。

対象が曖昧な場合（明確な参照先のない「なぜこのようにしているのですか？」など）は、会話の文脈（開いているファイル、最近の編集、直前に話題になった内容）から最善の推測をしてください。解釈が異なる場合にユーザーが修正できるよう、解釈を簡潔に伝えてから調査を進めてください。

ステップ 2. コードのアンカーを確立する

調査担当者を起動する前に、シードコンテキストをインラインで準備してください。ファイルパスと行範囲、主要なシンボル（関数、テーブル、イベント、エクスポート）、対象に関わる直近のコミット、マージコミットの PR 番号（件名にある (#1234) の形式）、関連する issue ID を含めます。最終更新コミットについては git blame -L <start>,<end> <file> を、リネームをたどるパッチ付きの全履歴については git log --follow -p -- <file> を、PR 番号を確認できる直近のコミットについては git log --oneline -20 -- <file> を、PR 番号を抽出するには git log -1 --format=%B <commit> を実行してください。その後、実質的な変更を含むコミットについて、PR 本文と議論を取得します。gh pr view <number> --json title,body,author,createdAt,mergedAt,labels,closingIssuesReferences,comments,reviews を実行してください。

対象が、サーバーは実行するもののこのリポジトリが管理していないリソースにある場合、またはサーバーのフォルダーが git リポジトリでない場合は、代わりにそのリソースの上流リポジトリと、サーバーが実行するバージョンをアンカーにしてください。両者の確認方法は SOURCES.md に記載されています。

このアンカーは、すべての調査担当者と統合担当者に渡してください。

ステップ 3. 並行して調査担当者を起動する

既定では、並行調査をすべて実施してください。 目標は網羅的なカバレッジマップの作成であり、最小限の調査ではありません。該当なしの結果も記録し、検索を省略しないでください。

ディスカバリー

調査員を開始する前に、自分のツール一覧にある MCP をサーバーごとに分類して列挙します。スキーマが読み込まれる前に名前だけが表示されているツールも含めます。それぞれを、以下の証拠カテゴリのいずれかに割り当てます。

1. ソース管理の履歴
2. イシュートラッカー
3. 長文ドキュメント
4. リアルタイムチャット
5. インフラストラクチャのオブザーバビリティ
6. エラートラッキング
7. プロダクト分析

ソース管理は git と gh を通じて常に利用でき、コードが GitHub にある場合は、gh の GitHub Issues でイシュートラッカーをカバーできます。その他については、MCP 名、サーバーの指示、ツール名、リソースの説明を基に分類します。複数のカテゴリに当てはまり得る MCP は、主要な証拠に合致するカテゴリを選びます。曖昧なケースはカバレッジマップに記録します。

ソースがあるカテゴリごとに調査員を 1 人ずつ、同時に開始して並行して実行し、それぞれが所有するツールまたは MCP は 1 つだけにします。1 人のエージェントに複数を担当させないでください。それぞれに why investigator: <category> という名前を付け、explore ロールを使用します。

各調査員への概要には、INVESTIGATOR-PROMPT.md に内容を記入したものに加えて、以下を含めます。

• 担当する MCP に合わせて調整した、SOURCES.md の該当カテゴリのセクション
• 対象コードが防御的に見える場合（null チェック、リトライ、タイムアウト、レート制限、機能フラグ、距離または権限のチェック）の SOURCES.md のインシデントコンテキストのセクション
• コードアンカーとユーザーの元の質問

各カテゴリが得意とすること

調査結果に何が期待できるか、カテゴリから結果が得られなかった場合にどのようなギャップがあるか、また、証明可能なほど無関係なまれなケースでのみ、スキップを正当化する方法を把握するために、以下を参考にしてください。

1. ソース管理（git 履歴、PR 用の gh、コードコメント、テスト）。必ず開始します。唯一、確実に利用できるソースです。レビュー時に記録された、実装時の根拠を見つけるのに最適です。
2. イシュートラッカー（GitHub Issues、または Linear や Jira の MCP）。変更の背景にあるプロダクトまたはユーザー向けの要因、つまりバグ報告やリクエストを見つけるのに最適です。
3. 長文ドキュメント（ドキュメントサイト、Wiki、Notion 形式の MCP）。コードになる前に書かれた長文の設計根拠を見つけるのに最適です。
4. リアルタイムチャット（Discord、Slack、Teams の MCP）。ドキュメントに残らなかったリアルタイムの議論を見つけるのに最適です。git、イシュー、ドキュメントの記録が乏しい場合は、特に重要です。
5. インフラストラクチャのオブザーバビリティ（Grafana、Datadog などの MCP）。コードの動機となった実行時の実態、つまりタイムアウト、リトライ、レート制限を見つけるのに最適です。
6. エラートラッキング（Sentry などの MCP）。防御的コードの動機となった具体的なエラー、つまり catch ブロック、nil ガード、型チェック、リトライを見つけるのに最適です。
7. プロダクト分析（データウェアハウスまたは分析 MCP）。コードに影響した使用状況データ、つまりフラグで制御されるコード、データ移行、「この数値はどこから来たのか」を見つけるのに最適です。

調査員をスキップする場合

最終的な Sources Consulted に記載する明示的な書面の根拠がある場合に限り、スキップできます。認められる理由は 2 つです。

• そのカテゴリに該当するソースがこの環境にない。 選択ではなくギャップとして記録します。「リアルタイムチャットはスキップしました。該当する MCP が利用できないため、会話の記録を検索できませんでした。」
• ソースが証明可能なほど無関係である。 「おそらく無関係」では不十分です。高い基準が求められます。「エラートラッキングはスキップしました。対象はビルドスクリプトで、実行時のコードパスがありません。」

対象が単一コミットの変更で、その PR の説明に回答がすでに完全に記載されている場合は、利用可能なすべてのカテゴリを検索しても重複するだけだと確認した後に限り、回答を直接提示できます。その旨を明記してください。これはまれなケースであるべきです。

ステップ 4. 統合する

why synthesizer という名前で、hardest tasks ロールの統合担当を 1 つ開始します。以下を渡します。

1. 調査員の調査結果。結果がなかったカテゴリや、根拠とともにスキップしたカテゴリも含めます
2. コードアンカー
3. ユーザーの元の質問
4. EPISTEMICS.md の認識論の枠組み
5. SYNTHESIZER-PROMPT.md の統合担当へのプロンプト

ステップ 5. 提示

シンセサイザーの出力をユーザーに提示します。明確さのために軽く編集したり、会話の内容を踏まえて補足を加えたりしてもかまいませんが、確信度を示す表現は書き換えないでください。

出力形式

構成は SYNTHESIZER-PROMPT.md のとおりです。「質問」「対象のコード」「判明したこと」「合理的に推測できること」「競合する仮説」「わからないこと」「参照した情報源」「確信度の要約」とします。必要に応じて調整できますが、確信度の区分は維持し、「参照した情報源」は、何も返さなかった調査担当者やスキップされた調査担当者も含め、担当者ごとに理由を添えて1行で記載してください。

「参照した情報源」の後に、ユーザーの「なぜ」という質問がこのコードの変更に先立つものである場合は、系譜に関する調査結果を、変更計画のための「維持／変更／回避／リスク」の制約セットにまとめてください。

避けるべきよくある失敗

• 直近の変更への偏り。最も新しいコミットが決定的なものだと考えることです。現在の状態は、過去のさまざまな判断が積み重なった結果である場合が多いため、さかのぼって調査してください。