why

理由

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

以下の各起動では、pstack 設定ファイル（Cursor では ~/.cursor/rules/pstack-models.mdc、それ以外のハーネスでは ~/.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 番号が確認できる直近 20 件のコミットを調べるには 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 の制約セットに変換してください。

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

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