why

理由

Claude Code では、このスキルに従う前に、セッションごとにClaude Code アダプターを一度読んでください。pstack スキル内の Cursor 名を Claude Code に対応付けています。

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

以下の各起動では、pstack-models.mdc ルール内のロール行とデフォルト値を指定します。model には、その行の値を設定します。ルールまたは行がない場合は、デフォルト値を設定します。値が auto または inherit-parent の場合は、model を未設定のままにします。Task ツールがスラッグを受け付けない場合は、デフォルト値を使い、その旨を伝えてください。デフォルト値も受け付けない場合は、エラーメッセージに記載された同じファミリーの有効なスラッグのうち、最も近いものを使ってください。poteto-mode スキルの Subagents セクションに従い、作業に応じて各サブエージェントの推論レベルと高速または標準の速度を選んでください。

すべての起動は 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> を実行してください。その後、内容に実質的な記述がある各コミットについて、gh pr view <number> --json title,body,author,createdAt,mergedAt,labels,closingIssuesReferences,comments,reviews を使って PR の本文と議論を取得してください。この基点をすべての調査担当エージェントと統合担当エージェントに共有してください。

ステップ 3. 複数の調査担当エージェントを並行して起動する

デフォルトでは、並行調査をすべて実施してください。 目標は完全な網羅性を確保することであり、最小限にとどめることではありません。該当なしという結果も記録し、調査を省略しないでください。

ディスカバリー

調査担当者を起動する前に、Cursor 環境で利用可能な MCP を一覧表示します。利用可能なツールのマップがある場合は、それを使用します。ない場合は、Cursor が公開している mcps/ ディレクトリを調べ、有効な MCP サーバーを確認します。

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

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

ソース管理は、git と gh を通じて常に利用できます。ほかの6カテゴリについては、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 の例を参考にして調整します
• 対象コードが防御的に見える場合は、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 の行、デフォルトは 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 の制約セットに変換してください。

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

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