目的
問題解決に規律あるアプローチを確立。修正を試みる前に根本原因調査を必須とする。
トリガー語
- 「デバッグ」
- 「バグ調査」
- 「根本原因を特定」
- 「体系的にトラブルシュート」
コアフレームワーク
4つの連続フェーズを必須とする：
1. 根本原因調査
- エラーを分析
- 問題を再現
- 最近の変更をレビュー
- システム層を通じてデータフローを追跡
2. パターン分析
- 動作する例を研究
- 壊れたコードとの違いを特定
3. 仮説とテスト
- 具体的な理論を形成
- 最小限の変更でテスト
4. 実装
- 失敗テストを作成
- 単一の修正を適用
- 結果を検証
絶対ルール
「根本原因調査なしに修正しない」
症状修正は新たな問題を生む。
回避すべきレッドフラグ行動
| 危険パターン | 問題 | |-------------|------| | 理解前に解決策を提案 | プロセスのバイパス | | 複数の同時変更 | 何が効いたかわからない | | 3回以上の修正試行 | アーキテクチャ再評価が必要 | | 時間圧力下での「クイックフィックス」 | 新バグの温床 |
エスカレーションポイント
3回以上の修正試行が失敗した場合
問題は単なるバグではなく、根本的なアーキテクチャ問題の可能性が高い。追加パッチではなく、設計への疑問が必要。
重要な洞察
体系的調査は、試行錯誤アプローチと比較して実際に時間を節約する
スラッシングと新バグ導入の両方を防ぐ。
ライセンス
MIT License (superpowers repository)