auto-debuggerlisted
Install: claude install-skill iamtatsuki05/dotfiles
# Auto Debugger
## 概要
エラーを受け取ったら、コード調査・printデバッグによる原因特定・修正・リグレッションテスト作成・ユーザー報告まで自律的に実行する。
## デバッグワークフロー
### Phase 1: コンテキスト収集
1. **エラー情報の整理**
- エラーメッセージ・例外タイプを抽出
- スタックトレースから呼び出し元ファイル・行番号を特定
- 直前の操作・変更内容を確認
2. **コードの読み込み**
- スタックトレースに含まれるファイルをすべて読み込む
- 関連する依存ファイル・モジュールも確認
- 既存テストファイルがあれば合わせて確認
3. **制約の確認**
- `.env` などのシークレットファイルは参照不可
- ただしスクリプトの実行は可能(print デバッグ・検証スクリプト作成・実行ができる)
### Phase 2: 仮説立案とprintデバッグによる調査
コードを読んだ後、問題箇所の仮説を立て、printデバッグスクリプトで検証する。
**仮説立案:**
- エラーの種類・発生箇所から疑わしい箇所をリストアップ(複数可)
- 優先度: スタックトレースの失敗行 → 呼び出し元 → 入力データ → 設定値
- エラー種別ごとの調査ポイントは `references/error-patterns.md` を参照
**printデバッグスクリプトの作成・実行:**
```python
# 例: 変数の値・型・フローを確認するデバッグスクリプト
# 本番コードは変更せず、独立したスクリプトとして作成する
import sys
sys.path.insert(0, '.')
# 問題の関数を直接呼び出して中間値を出力
from module import target_function
print(f"[DEBUG] input: {input_data!r}")
result = target_function(input_data)
print(f"[DEBUG] result: {result!r}")
```
デバッグ補助ファイルは、既存の一時ディレクトリ、`tmp/`、またはプロジェクトのテスト用 scratch 領域に置く。恒久的な成果物でない場合は修正完了後に削除するか、削除できない理由を報告する。
**調査ループ(原因特定まで繰り返す):**
1. 仮説に基づいたデバッグスクリプトを作成して実行
2. 出力結果から仮説を検証・絞り込む
3. 原因が特定できない場合は新たな仮説を立て、デバッグスクリプトを修正して再実行
4. 最大3回試行しても特定できない場合はユーザーに状況を報告して追加情報を求める
### Phase 3: 修正方針の検討と実装
原因が特定できたら修正方針を検討してから実装する。
**修正方針の検討:**
- 根本原因を解消する最小の変更を特定する
- 他の実装への影響範囲を確認する(Grep で呼び出し元を検索)
- 利用可能な実装スキルがあればそのスキルのルール・スタイルに従う
- Python コードなら `python-dev` スキルの規約
- Go コードなら `go-dev` スキルの規約
- TypeScript コードなら `typescript-dev` スキルの規約
**実装のルール:**
- **最小変更の原則**: 問題箇所のみを修正し、