DebugRuntime
目的
- •実行時の観測データを集め、推測ではなく証拠で原因を絞る
- •修正は最小にし、再発防止のテストまたは再現手順の固定化まで行う
- •一時的な計測コードは、解決後に必ず除去して汚さない
前提
- •このスキルは「ログを入れて再現して観測する」反復を中心に回す。Cursor Debug Mode と同じ設計思想。 :contentReference[oaicite:1]{index=1}
- •可能なら実行コマンドを自分で回し、無理ならユーザーに再現とログ貼り付けを依頼する（依頼は最小限、具体的なフォーマットで）。
進め方（3フェーズ）
- •事象定義と仮説生成
- •期待動作、実際の動作、再現手順、発生頻度、影響範囲を短く構造化する
- •仮説を5〜7個出し、観測で否定しやすい順に優先度を付ける
- •追加情報が足りない場合は、質問を増やさずに「必要最小の入力」だけ要求する（例：このコマンドの出力を貼る、特定ログを有効化して1回再現する、など）
- •計測（インストルメンテーション）と再現
- •優先度上位1〜2仮説を検証できる位置に、最小限のログまたは計測を入れる
- •ログにはユニークなプレフィックスを付ける（例：[dbg]）し、ノイズを増やしすぎない
- •秘密情報をログに出さない（トークン、Cookie、個人情報、鍵、決済情報）
- •再現の方法は以下の順で選ぶ
- •既存テストで再現できるなら、そのテストを実行して観測する
- •できないなら、最小の再現スクリプトや一時テストを作って再現する
- •それも無理なら、アプリを起動してユーザーに再現してもらいログを受け取る
実行コマンド例（Node/TS/Next を想定、適宜置換）
- •依存とバージョン把握
- •node -v
- •bun -v
- •pnpm -v
- •テスト
- •bunx vitest run
- •bunx vitest run path/to/test
- •開発起動
- •bun run dev
- •E2E
- •bunx playwright test
- •原因特定、修正、検証、後片付け
- •ログの証拠から、どの仮説が成立し、どれが棄却されたかを明示する
- •修正は「原因点に対する最短の変更」を優先する（2〜3行の修正で済むならそれを狙う）。 :contentReference[oaicite:2]{index=2}
- •検証は必ず行う
- •再現手順で再実行し、期待動作に戻ったことを確認する
- •可能なら回帰テストを1本追加し、同じ不具合が戻らない形にする
- •計測コード（ログ、ダンプ、暫定ガード）は、解決後に必ず除去する
出力フォーマット（この順で出す）
- •症状の要約（期待/実際/再現/頻度/影響）
- •仮説リスト（5〜7）と優先度、検証方法
- •追加した計測（どこに、何を、なぜ）
- •観測結果（ログ抜粋、スタック、時系列）
- •根本原因（1つに絞って説明）
- •修正内容（差分の意図、影響範囲、代替案）
- •検証手順（コマンドや操作手順）
- •後片付け（計測除去、テスト追加、ドキュメント更新）
ガードレール
- •証拠が出る前に大規模な書き換えをしない
- •1回の反復で入れるログは少なく、検証力が高いものに絞る
- •直したつもりを避けるため、必ず再現手順で確認する