why

理由

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

以下の各エージェントの起動設定では、pstack 設定ファイル（Cursor では ~/.cursor/rules/pstack-models.mdc、Claude Code では ~/.claude/rules/pstack-models.md、その他のハーネスでは ~/.agents/pstack-models.md）内のロール行とデフォルトを指定しています。model には、その行の値を設定してください。ファイルまたは行が存在しない場合は、デフォルトを設定します。値が auto または inherit-parent の場合は、model を設定しないでください。サブエージェントのツールがスラッグを受け付けない場合は、デフォルトを使用したことを伝えてください。デフォルトも受け付けない場合は、エラーメッセージまたは使用中のハーネスのモデル一覧から、同じ系統の最も近い有効なスラッグを使用してください。poteto-mode スキルの「Subagents」セクションに従い、各サブエージェントの推論レベルと速度（fast または standard）を、作業内容に合わせて選んでください。

すべての起動は generalPurpose、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> --json title,body,author,createdAt,mergedAt,labels,closingIssuesReferences,comments,reviews です。この根拠情報を、すべての調査エージェントと統合エージェントに共有してください。

ステップ 3：並行して調査エージェントを起動する

原則として、並行調査をすべて実施してください。 目標は最小限の調査ではなく、網羅的なカバレッジマップです。見つからなかった情報も記録し、検索を省略しないでください。

検出

調査担当者を起動する前に、ハーネスに接続されている MCP サーバーを列挙します。利用可能なツールのマップがある場合は、それを使用します。Cursor では、MCP サーバーを有効にするために公開されている mcps/ ディレクトリを調べることもできます。他のハーネスでは、MCP ツールは通常、ツール名にサーバー名を含めてツール一覧に表示されます（例：Claude Code の mcp__<server>__<tool>）。

利用可能な各 MCP を、次の証拠カテゴリのいずれかに分類します。

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

ソース管理には、常に git と gh を利用できます。残りの 6 カテゴリは、MCP 名、サーバーの説明、ツール名、リソースの説明を使って分類します。複数のカテゴリに当てはまる可能性がある MCP は、主な証拠に最も合うカテゴリを選びます。曖昧なケースはカバレッジマップに記録します。

該当する MCP があるカテゴリごとに調査担当者を 1 人起動します。全員を 1 つのメッセージで起動して並行して実行し、それぞれが所有するツールまたは MCP は 1 つだけにします。1 人のエージェントに複数の MCP を担当させないでください。model：why investigators の行。デフォルトは grok-4.7-xhigh-fast です。

各調査担当者へのプロンプトは、references/investigator-prompt.md に必要事項を記入したものに、以下を追加します。

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

その他のハーネス

このスキルの起動処理では、Cursor の Task ツールを使用します。他のハーネスでは、サブエージェント用ツールを使用してください。Claude Code では Agent（subagent_type: general-purpose）、OpenCode では task（subagent_type: general）、Codex では spawn_agent を使います。プロンプトとモデルはそのまま維持します。ツールにないパラメーターは省略します。Pi の拡張機能なしの環境のように、ハーネスにサブエージェント用ツールがない場合は、各調査担当者の作業を自分で順番に行います。

調査担当者の構成：利用可能な証拠カテゴリごとに 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 の行、デフォルトは claude-opus-5-5-xhigh を指定します。統合役は次のものを受け取ります。

1. 調査員の調査結果。null の結果や、正当な理由とともにスキップされたカテゴリも含みます
2. コードアンカー
3. ユーザーの元の質問
4. references/epistemics.md の認識論フレームワーク
5. references/synthesizer-prompt.md の統合役プロンプトテンプレート

ステップ 5. 提示する

統合役の出力をユーザーに提示します。明確さのために軽く編集したり、会話からの文脈を追加したりしてもかまいませんが、確信度の表現は書き換えないでください。

出力形式

構成は references/synthesizer-prompt.md にあるものと同じです。「The Question」「The Code in Question」「What We Found」「What We Can Reasonably Infer」「Competing Hypotheses」「What We Don't Know」「Sources Consulted」「Confidence Summary」。必要に応じて調整してかまいませんが、確信度の分離は維持し、「Sources Consulted」は調査員ごとに 1 行とし、何も返さなかった調査員やスキップされた調査員も理由とともに含めてください。

「Sources Consulted」の後に、ユーザーの why の質問がこのコードを変更する前段階である場合は、系譜の調査結果を、変更を計画するための Preserve / Change / Avoid / Risk の制約セットに変換してください。

避けるべきよくある失敗パターン

• 直近性バイアス。最新のコミットが権威的であるとみなしてしまうこと。現在の形は、多くの場合、以前の多数の決定が積み重なった結果です。過去にさかのぼって追跡してください。