Bug Fix Workflow
バグ修正の標準化されたワークフロー。TDD（Red-Green-Refactor）とroot cause analysisを組み合わせる。
ワークフロー
Phase 1: 理解
-
バグの報告・症状を確認する
- ユーザーからの報告、issueの内容、エラーメッセージを把握
- 再現条件を明確にする
-
関連コードを読む
- バグが発生している箇所のソースコードを読む
- 呼び出し元・呼び出し先の依存関係を理解する
- 既存テストを確認: 関連するテストファイルを読み、テストパターン（アサーション、データ構造、ヘルパー関数）を把握する
-
根本原因を特定する（5 Whys）
- エラーメッセージの最初を確認する（最後ではない）
- 症状ではなく根本原因を探る
- 仮定に頼らず、コードを実際に読んで確認する
- 確信が持てない場合は logic-validator で推論を検証する
Phase 2: Red（失敗するテストを書く）
- バグを再現する失敗テストを書く
- 既存テストのパターンに合わせる: アサーションスタイル、データ構造、命名規則を既存テストから踏襲する
- テストがバグの症状を正確に捉えていることを確認する
- テストを実行し、確実に失敗することを確認する
Phase 3: Green（最小限の修正）
- テストが通る最小限のコード修正を行う
- 根本原因に対する修正のみ行う
- 周辺コードのリファクタリングは行わない
- テストを実行し、新しいテストが通ることを確認する
Phase 4: Refactor（リグレッション確認）
-
全テストスイートを実行してリグレッションがないことを確認する
- 新しいテストだけでなく、既存テスト全体を実行する
- lint/type checkも実行する
-
必要に応じてコードを整理する
- テストが全て通った状態でのみリファクタリングする
- 修正に直接関係する箇所のみ
Phase 5: まとめ
- バグの原因と修正内容をサマリーする
- 根本原因は何だったか
- どのように修正したか
- 影響範囲と確認した内容
注意事項
- 症状的修正を避ける: 「とりあえず動く」修正ではなく根本原因に対処する
- 既存パターンを尊重する: テスト構造、エラーハンドリング、コーディングスタイルをプロジェクトに合わせる
- 最小限の変更: バグ修正に直接関係ない変更は別コミットにする
- debugging.md を参照: 詳細なデバッグ手順は
@~/.claude/rules/debugging.mdに従う