why

理由

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

以下の各スポーンでは、pstack モデル設定内のロール行とデフォルトを指定しています。Skill ツールを pstack-harness で呼び出し、モデル、労力度、エージェントの種類を解決してください。「ロールのスポーン」セクションでは、設定がない場合、inherit-parent、および拒否された値についても説明しています。

すべてのスポーンは general-purpose で、readonly: false（エージェントモード）です。readonly／Ask モードは使用しないでください。 このモードでは MCP アクセスが失われ、MCP を利用する調査者と、引用箇所を抜き取り確認する統合担当者が機能しなくなります。調査者はそれでも、何も書き込まないでください。

運用姿勢

慎重かつ正確に調査する姿勢で臨んでください。把握していることと推測していることを正直に区別してください。確信度に関する枠組みと表現の指針については、references/epistemics.md を読んでください。統合担当者はこれに従う必要があります。

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

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

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

ステップ 2. コードの基点を確立する

調査者をスポーンする前に、種となるコンテキストをインラインで構築します。ファイルパスと行範囲、主要なシンボル（関数、クラス、定数）、対象に触れた直近のコミット、マージコミットからの PR 番号（件名にある (#1234) の形式）、および関連するチケット 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> -R <host>/<owner>/<repo> --json title,body,author,createdAt,mergedAt,labels,closingIssuesReferences,comments,reviews です。<host>/<owner>/<repo> には origin の fetch URL を使用してください。gh がない場合、認証されていない場合、またはクエリに失敗した場合は、該当する PR をコードの基点で未確認として示し、「参照した情報源」に不足している情報を明記してください。この基点はすべての調査者と統合担当者に渡します。

ステップ 3. 並行調査者をスポーンする

基本的には並行調査をすべて実施してください。 目標は最小限の調査ではなく、網羅的なカバレッジマップを作ることです。該当なしという結果も記録し、検索を省略しないでください。

検出

調査担当者を起動する前に、このセッションで利用可能な MCP サーバーをツール一覧から確認してください（mcp__ が先頭に付くツール名は、そのサーバーを示します）。

利用可能な各 MCP を、次の証拠カテゴリのいずれかに割り当ててください。

1. ソース管理の履歴
2. 課題／チケットトラッカー
3. 長文ドキュメント
4. リアルタイムのチームチャット
5. インフラストラクチャの可観測性
6. エラー／例外トラッキング
7. プロダクト分析ウェアハウス

ソース管理は git と gh で常に利用できます。ほかの6カテゴリについては、MCP 名、サーバーの説明、ツール名、リソースの記述子を使って分類してください。ある MCP が複数のカテゴリに当てはまる場合は、主な証拠に一致するカテゴリを選んでください。曖昧なケースはカバレッジマップに記録してください。

対応する MCP があるカテゴリごとに調査担当者を1人起動し、全員が並行して動作するよう、1つのメッセージで起動してください。各担当者が受け持つツールまたは MCP は厳密に1つにしてください。1人のエージェントに複数の MCP を担当させないでください。起動には pstack-harness を指定して Skill ツールを呼び出してください。その Spawn a role セクションでロールを解決し、この CLI の起動呼び出しを構築します。model は why investigators の行に従い、デフォルトは sonnet です。

各調査担当者へのプロンプトには、記入済みの references/investigator-prompt.md と、次の内容を含めてください。

• 選択した MCP 用のカテゴリ別プレイブック references/sources/<source>.md。references/source-playbook.md の例を参考に調整してください。
• 対象コードが防御的な処理に見える場合は、references/sources/incident-postmortem.md（null チェック、リトライ処理、タイムアウト処理、レート制限、機能フラグ、送信先制限、OOM ハンドラーなど）
• コードアンカーとユーザーの元の質問

調査担当者の割り当て。利用可能な証拠カテゴリごとに1人

以下の各カテゴリには、それぞれ固有の「なぜ」を明らかにする役割があります。「最も得意な点」を参考に、どのような情報が得られるかを見極め、何も見つからなかった場合は不足しているカテゴリを明示してください。また、まれに明らかに無関係と証明できる場合に限り、調査を省略する理由を示してください。

1. ソース管理（git の履歴、PR 用の gh、コードコメント、テスト）。必ず起動してください。唯一、常に利用できるソースです。最も得意な点は、レビュー時に記録された実装上の判断理由です。
2. 課題／チケットトラッカー（例：Linear、Jira、GitHub Issues、Plane、Shortcut MCP）。最も得意な点は、製品またはビジネス上の要因です。エンジニアリングの外部にある「なぜ」を明らかにするのに特に有効です。
3. 長文ドキュメント（例：Notion、Confluence、Google Docs、Coda MCP）。最も得意な点は、実装前に文書化された長文の設計上の理由です。
4. リアルタイムのチームチャット（例：Slack、Discord、Microsoft Teams、Mattermost MCP）。最も得意な点は、文書に残されなかったリアルタイムの議論です。ソース管理、チケット、ドキュメントの記録が乏しい場合は、特に重要です。
5. インフラストラクチャの可観測性（例：Datadog、New Relic、Honeycomb、Grafana、Splunk MCP）。最も得意な点は、コードの動機となったインフラストラクチャや実行時の状況です。対象コードがインフラストラクチャのシグナル（タイムアウト、リトライ、レート制限、サーキットブレーカーなど）に対応している場合に特に有効です。
6. エラー／例外トラッキング（例：Sentry、Rollbar、Bugsnag、Airbrake MCP）。最も得意な点は、防御的なコードや修正コードの動機となった具体的な例外とエラーの推移です。catch ブロック、null ガード、型チェック、リトライなどの防御処理に特に有効です。
7. プロダクト分析ウェアハウス（例：Databricks、Snowflake、BigQuery、ClickHouse、dbt、Redshift MCP）。最も得意な点は、コードを形作ったプロダクトやデータの実情です。機能フラグで制御されるコード、実験に基づくリリース、データ移行、「この数値はどこから来たのか」という疑問の解明に特に有効です。

調査担当者を省略する場合

最終的な「参照した情報源」に記載する、明示的かつ書面による根拠がある場合に限ります。正当な理由は次の2つです。

• この環境では、そのカテゴリに該当する MCP が利用できない場合。 選択ではなく、ギャップとして示してください。「リアルタイムのチームチャットは調査対象外です。該当する MCP が利用できないため、会話の記録を検索できませんでした。」
• 情報源が、単に「おそらく無関係」なのではなく、明らかに無関係である場合。 高い基準が求められます。「エラー／例外トラッキングは調査対象外です。対象はビルド時スクリプトであり、実行時のコードパスがありません。」

スコープの評価から、単一コミットで完結する単純な対象であり、PR の説明に答えがすべて記載されていると判断できる場合は、利用可能な7つのカテゴリすべてで検索しても冗長になることを確認した後に限り、回答をそのまま提示してもかまいません。その旨を明示してください。これはまれなケースです。

ステップ4. 統合する

統合担当者を1人起動します。model には why synthesizer の行の値を指定し、既定値は opus です。次の情報を渡します。

1. 調査担当者の調査結果。該当なしの結果や、根拠を示して省略したカテゴリも含みます。
2. コードの根拠箇所
3. ユーザーの元の質問
4. references/epistemics.md の認識論フレームワーク
5. references/synthesizer-prompt.md の統合担当者向けプロンプトテンプレート

ステップ5. 提示する

統合担当者の出力をユーザーに提示します。明確さのために軽く編集したり、会話の内容から背景情報を補足したりしてもかまいませんが、確信度に関する表現は書き換えないでください。

出力形式

構成は references/synthesizer-prompt.md に記載されているとおりです。「質問」、「対象のコード」、「調査で判明したこと」、「合理的に推測できること」、「対立する仮説」、「分からないこと」、「参照した情報源」、「確信度の概要」を含めます。必要に応じて調整してもかまいませんが、確信度の区分は維持してください。また、「参照した情報源」は調査担当者1人につき1行とし、何も見つからなかった担当者や、省略した担当者も、その理由とともに記載してください。

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

よくある失敗を避ける

• 直近の変更への偏り。 最新のコミットが決定的な情報だと思い込まないでください。現在の状態は、多くの場合、過去のさまざまな判断が積み重なったものです。遡ってたどってください。