Systematic Debugging
📋 実行前チェック(必須)
このスキルを使うべきか?
- • バグが発生している?
- • テストが失敗している?
- • 予期しない挙動がある?
- • 本番障害に対応している?
前提条件
- • 症状を正確に把握しているか?
- • エラーメッセージを記録したか?
- • 環境情報(OS、バージョン等)を確認したか?
禁止事項の確認
- • 推測だけで修正しようとしていないか?
- • 再現手順を確立せずに修正しようとしていないか?
- • 根本原因を特定せずに対症療法しようとしていないか?
- • 3回以上失敗しているのに同じアプローチを続けていないか?
- • 試した内容を記録せずに進めようとしていないか?
トリガー
- •バグ発生時
- •テスト失敗時
- •予期しない挙動発見時
- •本番障害対応時
🚨 鉄則
推測での修正禁止。根本原因を特定してから修正。
4フェーズ(⛔ スキップ禁止)
Phase 1: 再現
🛑 100%再現可能にする。再現できなければ修正提案禁止。
code
□ 症状を正確に記録 □ 最小再現ケースを作成 □ 環境情報を収集 □ 再現手順を文書化
Phase 2: 境界トレース
どの層で問題が発生しているか特定。
code
□ フロントエンド / バックエンド / DB / 外部サービス □ 入力値は正しいか? □ どの時点でデータが壊れるか? □ ログで異常箇所を特定
Phase 3: 根本原因特定
「なぜ?」を繰り返す。
code
症状: ユーザーが保存できない → なぜ? APIが500を返す → なぜ? DBクエリが失敗 → なぜ? NULL制約違反 → なぜ? バリデーションが欠落 ← 🎯 根本原因
Phase 4: TDDで修正
- •バグを再現するテストを書く(RED)
- •最小限の修正(GREEN)
- •修正が正しいことを確認
- •リグレッションがないことを確認
⚠️ 失敗パターン
3回以上の修正失敗 → 🛑 アーキテクチャを疑う。ユーザーと相談。
デバッグ記録テンプレート
code
## バグ: [症状の一行サマリ] ### 再現手順 1. ... 2. ... 3. ... ### 環境 - OS: - バージョン: - ブラウザ(該当する場合): ### エラーメッセージ
(エラー内容)
code
### 試したこと 1. [試した内容] → [結果] 2. [試した内容] → [結果] ### 根本原因 [特定した原因] ### 修正方針 [どう修正するか]
🚫 禁止事項まとめ
- •推測だけで修正する
- •再現せずに修正する
- •根本原因を特定せずに対症療法
- •試した内容を記録しない
- •同じ失敗を繰り返す