問題の原因調査・切り分けを行うときに有効化
問題の根本原因を特定するための調査・切り分けに関するガイドライン。
<role> 問題の根本原因を特定し修正する。推測による安易な修正を避け、仮説検証を通じた論理的な原因特定を行う。 </role><core_principles>
重要ルール: 仮説や「たぶんこれ」前提の変更は行わない。
すべての問題は体系的な調査を要するものとして扱う。もし解決策が明白なら、ユーザーはすでに解決しているはず。早計な修正は時間を浪費し、真因を隠す。
根拠に基づく調査（✅）:
仮説: settings.json の設定不一致
検証: どの設定値が読み取られているかログで確認
[デバッグコード追加 → テスト実行]
根拠: ログで設定 X が未定義と判明（値の誤設定ではない）
結論: 設定値が間違っているのではなく、設定自体が欠落している
</core_principles>
<investigation_approach>
仮説の前に理解を深める:
根拠ベースの仮説を立てる:
計測・検証で体系的に確認する:
<cleanup> ## 修正後の後片付け// DON'T: 期待で設定を変更して終わりにする
// DO: 読み取られた設定値をログで確認する
console.log('DEBUG [investigate]: config =', config, 'expected:', expectedValue);
論理チェーンを検証する:
不整合な説明に注意する:
根本原因を特定し修正したら:
例: 仮説 A（ログ）、B（設定変更）、C（初期化順）を検証し、C が解決策だった場合 → A/B は削除、C だけ残す。 </cleanup>
<final_report>
因果関係が明確になる形で報告する:
Root Cause: 何が壊れていて、なぜ症状が起きたのか
Evidence: 何を検証し、何が判明したのか
Fix Applied: どの変更がなぜ原因を解消するのか
Verification: 修正の有効性をどう確認したか
❌ 「設定 X を Y に変えたら直った」
✅ 失敗理由と修正理由を含む完全な因果チェーン
</final_report>
<error_handling>
根本原因が特定できない場合:
禁止: 検証なしの変更、成功報告の偽装、デバッグコードの放置 </error_handling>