Systematic Debugging

トリガー条件

以下のいずれかに該当する場合、このスキルを必ず発動する:

• バグ・テスト失敗・エラーに遭遇したとき
• 「なぜか動かない」「期待通りに動かない」と報告されたとき
• 修正を試みたが直らないとき（2回以上失敗）
• 原因不明の挙動を調査するとき

発動タイミング: 修正コードを書く前に必ず実行する。

前提条件

• 対象のコード・ログ・エラーメッセージにアクセスできること
• テスト実行環境が利用可能であること
• 再現手順が存在すること（存在しない場合はPhase 1で作成）

鉄則

推測での修正禁止。根本原因を特定してから修正。

4フェーズ (スキップ禁止)

Phase 1: 再現

100%再現可能にする。再現できなければ修正提案禁止。

- [ ] 症状を正確に記録
- [ ] 最小再現ケースを作成
- [ ] 環境情報を収集
- [ ] 再現手順を文書化

Phase 2: 境界トレース

どの層で問題が発生しているか特定。

- [ ] フロントエンド / バックエンド / DB / 外部サービス
- [ ] どの時点でデータが壊れるか?

Phase 3: 根本原因特定

「なぜ?」を繰り返す。

症状 → なぜ? → なぜ? → なぜ? → 根本原因

Phase 4: TDDで修正

1. バグを再現するテストを書く (RED)
2. 最小限の修正 (GREEN)
3. リグレッションがないことを確認

失敗パターン

3回以上の修正失敗 → アーキテクチャを疑う。ユーザーと相談。

デバッグ記録テンプレート

## バグ: [一行サマリ]
### 再現手順: 1. ... 2. ...
### 環境: OS / バージョン
### エラーメッセージ: (原文)
### 試したこと: [内容] → [結果]
### 根本原因:
### 修正方針:

禁止事項

• 推測だけで修正する
• 再現せずに修正する
• 根本原因を特定せずに対症療法
• 試した内容を記録しない
• 同じ失敗を繰り返す
• Phase 1〜4をスキップして修正コードを書く
• エラーメッセージを原文確認せずに対応する

一次ソース確認

• コード確認: 実ファイルを読む（推測禁止）
• API/関数: 公式ドキュメントまたは定義元を確認
• エラー: ログ原文を必ず引用する