auto-debuggerlisted

# Auto Debugger ## 概要 エラーを受け取ったら、コード調査・printデバッグによる原因特定・修正・リグレッションテスト作成・ユーザー報告まで自律的に実行する。 ## デバッグワークフロー ### Phase 1: コンテキスト収集 1. **エラー情報の整理** - エラーメッセージ・例外タイプを抽出 - スタックトレースから呼び出し元ファイル・行番号を特定 - 直前の操作・変更内容を確認 2. **コードの読み込み** - スタックトレースに含まれるファイルをすべて読み込む - 関連する依存ファイル・モジュールも確認 - 既存テストファイルがあれば合わせて確認 3. **制約の確認** - `.env` などのシークレットファイルは参照不可 - ただしスクリプトの実行は可能（print デバッグ・検証スクリプト作成・実行ができる） ### Phase 2: 仮説立案とprintデバッグによる調査 コードを読んだ後、問題箇所の仮説を立て、printデバッグスクリプトで検証する。 **仮説立案:** - 先に「1コマンドで成否が分かる再現方法」を確保する。再現が不安定・困難な bug や性能退行では、`diagnose` skill の方法論（フィードバックループ構築、反証可能な複数仮説）を併用する - エラーの種類・発生箇所から疑わしい箇所をリストアップ（複数可） - 優先度: スタックトレースの失敗行 → 呼び出し元 → 入力データ → 設定値 - 見落としやすい gotcha と横断的な調査手順は `references/error-patterns.md` を参照 **printデバッグスクリプトの作成・実行:** 本番コードは変更せず、問題の関数を直接呼び出す独立スクリプトを作成する。入力・中間値・戻り値を `[DEBUG]` プレフィックス付きで出力し、値・型・実行フローを確認する。 デバッグ補助ファイルは、既存の一時ディレクトリ、`tmp/`、またはプロジェクトのテスト用 scratch 領域に置く。恒久的な成果物でない場合は修正完了後に削除するか、削除できない理由を報告する。 **調査ループ（原因特定まで繰り返す）:** 1. 仮説に基づいたデバッグスクリプトを作成して実行 2. 出力結果から仮説を検証・絞り込む 3. 原因が特定できない場合は新たな仮説を立て、デバッグスクリプトを修正して再実行 4. 最大3回試行しても特定できない場合はユーザーに状況を報告して追加情報を求める ### Phase 3: 修正方針の検討と実装 原因が特定できたら修正方針を検討してから実装する。 **修正方針の検討:** - 根本原因を解消する最小の変更を特定する - 他の実装への影響範囲を確認する（Grep で呼び出し元を検索） - 利用可能な実装スキルがあればそのスキルのルー���・スタイルに従う - Python コードなら `python-dev` スキルの規約 - Go コードなら `go-dev` スキルの規約 - TypeScript コードなら `typescript-dev` スキルの規約 **実装のルール:** - **最小変更の原則**: 問題箇所のみを修正し、リファクタリングは行わない - WHY が必要な箇所のみコメントを追加する - 複数箇所を修正する場合は依存順に実施する ### Phase 4: リグレッ