why

コードは動機ではなく仕組みです。コードが何をするかは読み取れますが、なぜ存在するのかは記録の中にあります。コミット、PR、チケット、ドキュメント、チャット、テレメトリーなど、そのすべてが部分的で、ときには矛盾しています。その記録から、何がコードを形作ったのかを答え、記録からは分からない部分も明示します。

1. 質問を明確にする

対象とは、質問が関係するコードのことです。コードの一部、パターン、または名前の付いた設計上の判断が該当します。対象が曖昧な場合は、会話の文脈（開いているファイル、最近の編集内容、直前に話し合ったこと）から読み取り、その解釈を一行で示してから進めます。

質問自体に答えが含まれている場合（「パフォーマンスのためだと思うのですが？」など）、それは仮説です。シンセサイザーが検証する候補の一つとして、質問の横に記します。

対象と質問をそれぞれ一行で書き、質問に仮説が含まれる場合は、その横に仮説を記したら完了です。

2. 対象範囲を整理する

このセッションの MCP サーバー（mcp__<server>__ のツール接頭辞）を一覧にし、それぞれを次の7つの情報源のいずれかに割り当てます。ソース管理（git と gh により常に対象）、チケット、ドキュメント、チャット、オブザーバビリティ、エラー、分析です。2つに当てはまるサーバーは、主な証拠に対応する方を選びます。エラーも追跡するプロダクト分析サーバーは「分析」、インシデント記録も保持する監視サーバーは「オブザーバビリティ」です。ブラウザー、ファイルシステム、ワークツリー用ツールなど、過去の記録を保持しないサーバーは、どこにも割り当てません。その結果を対象範囲マップとして記録します。

すべての情報源について、対象（サーバー、またはソース管理の場合は git と gh）か、1行のスキップ理由を添えたスキップのどちらかが記されていたら完了です。スキップ理由は、サーバーが存在しない、またはこの対象では対象外（ビルド時スクリプトにエラー追跡機能がない場合など）のいずれかです。単に疑わしいだけの情報源は対象に含めます。

3. 根拠を集める

アンカー担当（subagent_type: Explore）をディスパッチします。プロンプトには、git と gh の呼び出し方法、および各セクションに記録する内容を示した references/anchor.md のパス、対象、質問と仮説を含めます。アンカーのすべてのセクションが記入され、防御的読み取りの結果が「はい」または「いいえ」で返されたら完了です。

4. 調査する

対象となる情報源ごとに調査担当者を1人ずつ割り当て、一度のメッセージでディスパッチします。各プロンプトには次を含めます。

• 最初に読む references/investigator.md のパス
• 次に読む、情報源に対応するプレイブックのパス references/sources/<source>.md（ソース管理の場合は source-control.md）
• アンカー
• 質問と仮説
• アンカーが防御的と示した場合：プレイブックと並行して実行する、横断的なインシデント調査 references/incident.md のパス

対象となる情報源ごとに専任の調査担当者が1人ずつ割り当てられ、担当が統合されておらず、それぞれがブリーフの各セクションに沿った調査結果を返し、すべてのプロンプトに上記の内容が含まれていたら完了です。

5. 統合する

すべての調査担当者から返答を受け取ったら、references/synthesizer.md と references/epistemics.md のパスを指定してシンセサイザーをディスパッチし、次を含めます。

• 各調査担当者の調査結果（原文のまま）
• アンカー
• 質問と仮説
• スキップ理由を含む対象範囲マップ

「参照した情報源」に7つすべての情報源が含まれるレポートが返されたら完了です。

6. 提示する

シンセサイザーのレポートを、確信度を示す表現を保ったまま伝えます。読み手の助けになる場合は、会話の文脈を加えます。シンセサイザーが記したすべてのティアラベル、引用、Unknownを含むレポートをユーザーが受け取ったら完了です。