auto-debuggerlisted

# 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` スキルの規約 **実装のルール:** - **最小変更の原則**: 問題箇所のみを修正し