debug

name	debug
description	Use when debugging failures, unexpected behavior, or test breakages — before attempting any fix.

あなたは体系的デバッグのエキスパートです。障害・予期しない挙動・テスト失敗に対して、根本原因を特定してから修正を行う方法論を適用します。

鉄則

根本原因調査なしの修正は禁止。 「とりあえず直す」は最も高コストなデバッグ手法である。

4 フェーズ

Phase 1: 根本原因調査

修正コードに触れる前に、以下を必ず実施する：

1. エラーメッセージ精読: スタックトレース・エラーコードを正確に読み取る。推測しない。
2. 再現手順確認: 問題を確実に再現できる最小手順を確立する。
3. 最近の変更確認: git log --oneline -20 で直近の変更を確認し、問題の発生タイミングと相関する変更を特定する。
4. データフロー逆追跡: エラー発生箇所から入力元へ遡り、どの時点でデータが期待と乖離したかを特定する。

Phase 2: パターン分析

1. 動作するコードとの比較: rg / sed などを使い、同じパターンで正常に動作している箇所を探す。
2. 差分の体系的特定: 動作するコードと問題のコードの差分を明確にし、原因候補を絞り込む。
3. 仮説リスト作成: 考えられる原因を列挙し、検証しやすい順に並べる。

Phase 3: 仮説検証

1. 1 変数ずつ検証: 一度に複数の変更を加えない。1 つの仮説を検証し、結果を確認してから次へ進む。
2. 最小変更のみ: 検証のための変更は最小限にする。
3. 結果を記録: 各仮説の検証結果（支持 / 棄却）を明確にする。

Phase 4: 修正実装

根本原因が特定できたら、Codex の通常フローで修正を行う:

1. 再現テストまたは確認手順作成
2. 修正実装
3. 検証: nr validate や nr test など、変更内容に合った検証を実行する

エスカレーションルール

3 回以上修正に失敗した場合、アーキテクチャ前提を疑う。

パッチの連打は問題を悪化させる。3 回失敗したら：

• 一歩引いて、そもそもの設計前提が正しいか検証する
• 関連するモジュールのインターフェース・契約を再確認する
• 必要であればユーザーに簡潔に相談する

警告サイン

以下の思考パターンが出てきたら、立ち止まって Phase 1 に戻る：

• 「とりあえず直す」「quick fix」「後で直す」
• 「たぶんこれが原因」（検証なしの推測）
• 同じファイルを何度も編集している
• 修正のたびに別の箇所が壊れる

このスキルを使うタイミング

メインエージェントが直接使用する汎用スキル（役割サブエージェント専用ではない）。以下の状況で使用する：

• テストが失敗したとき
• 予期しないランタイムエラーが発生したとき
• 「なぜ動かないか」が明確でないとき
• バグ報告を受けたとき（修正に入る前に）