Systematic Debugging
トリガー条件
以下のいずれかに該当する場合、このスキルを必ず発動する:
- バグ・テスト失敗・エラーに遭遇したとき
- 「なぜか動かない」「期待通りに動かない」と報告されたとき
- 修正を試みたが直らないとき（1回以上失敗）
- 原因不明の挙動を調査するとき
発動タイミング: 修正コードを書く前に必ず実行する。
前提条件
- 対象のコード・ログ・エラーメッセージにアクセスできること
- テスト実行環境が利用可能であること
- 再現手順が存在すること（存在しない場合はPhase 1で作成）
鉄則
推測での修正禁止。根本原因を特定してから修正。
4フェーズ (スキップ禁止)
Phase 1: 再現
100%再現可能にする。再現できなければ修正提案禁止。
- [ ] 症状を正確に記録
- [ ] 最小再現ケースを作成
- [ ] 環境情報を収集
- [ ] 再現手順を文書化
Phase 2: 境界トレース
どの層で問題が発生しているか特定。
- [ ] フロントエンド / バックエンド / DB / 外部サービス
- [ ] どの時点でデータが壊れるか?
Phase 3: 根本原因特定
「なぜ?」を繰り返す。最低2回、症状の原因層（データ・責務・契約のいずれか）に到達するまで（3-5回目安）。
症状 → なぜ? → なぜ? → なぜ? → 根本原因
Phase 4: TDDで修正
- バグを再現するテストを書く (RED)
- 最小限の修正 (GREEN)
- リグレッションがないことを確認
失敗パターン
修正が繰り返し失敗した場合、以下の段階で対応する:
- 2回失敗: Phase 1（再現）からやり直す。最小再現ケースと境界トレースを再検証。前回の根本原因仮説が誤っていた前提で再分析
- 3回以上失敗: アーキテクチャを疑う。ユーザーと相談（責務境界・層分離・データフローの構造的問題の可能性）
いずれの段階でも、試した内容と失敗理由は failure-logging スキルで記録する（同じ失敗を繰り返さないため）。
デバッグ記録テンプレート
## バグ: [一行サマリ]
### 再現手順: 1. ... 2. ...
### 環境: OS / バージョン
### エラーメッセージ: (原文)
### 試したこと: [内容] → [結果]
### 根本原因:
### 修正方針:
禁止事項
- 推測だけで修正する
- 再現せずに修正する
- 根本原因を特定せずに対症療法
- 試した内容を記録しない
- 同じ失敗を繰り返す
- Phase 1〜4をスキップして修正コードを書く
- エラーメッセージを原文確認せずに対応する
一次ソース確認
- コード確認: 実ファイルを読む（推測禁止）
- API/関数: 公式ドキュメントまたは定義元を確認
- エラー: ログ原文を必ず引用する