name: systematic-debugging description: バグやテスト失敗に遭遇した際に使用。修正前の4フェーズ根本原因分析を強制。

Systematic Debugging

📋 実行前チェック(必須)

このスキルを使うべきか?

• バグが発生している?
• テストが失敗している?
• 予期しない挙動がある?
• 本番障害に対応している?

前提条件

• 症状を正確に把握しているか?
• エラーメッセージを記録したか?
• 環境情報(OS、バージョン等)を確認したか?

禁止事項の確認

• 推測だけで修正しようとしていないか?
• 再現手順を確立せずに修正しようとしていないか?
• 根本原因を特定せずに対症療法しようとしていないか?
• 3回以上失敗しているのに同じアプローチを続けていないか?
• 試した内容を記録せずに進めようとしていないか?

トリガー

• バグ発生時
• テスト失敗時
• 予期しない挙動発見時
• 本番障害対応時

🚨 鉄則

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

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

Phase 1: 再現

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

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

Phase 2: 境界トレース

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

□ フロントエンド / バックエンド / DB / 外部サービス
□ 入力値は正しいか?
□ どの時点でデータが壊れるか?
□ ログで異常箇所を特定

Phase 3: 根本原因特定

「なぜ?」を繰り返す。

症状: ユーザーが保存できない
→ なぜ? APIが500を返す
→ なぜ? DBクエリが失敗
→ なぜ? NULL制約違反
→ なぜ? バリデーションが欠落 ← 🎯 根本原因

Phase 4: TDDで修正

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

⚠️ 失敗パターン

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

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

## バグ: [症状の一行サマリ]

### 再現手順
1. ...
2. ...
3. ...

### 環境
- OS: 
- バージョン: 
- ブラウザ(該当する場合): 

### エラーメッセージ

(エラー内容)

### 試したこと
1. [試した内容] → [結果]
2. [試した内容] → [結果]

### 根本原因
[特定した原因]

### 修正方針
[どう修正するか]

🚫 禁止事項まとめ

• 推測だけで修正する
• 再現せずに修正する
• 根本原因を特定せずに対症療法
• 試した内容を記録しない
• 同じ失敗を繰り返す