Debug (バグ原因特定→修正モード)

バグや問題の原因を仮説駆動で特定し、修正まで一貫して行うスキル。

フロー概要

1. •問題の把握・情報収集
2. •仮説の立案 (最低 2 つ)
3. •仮説の検証 (並列)
4. •原因の特定・報告
5. •修正 (自動遷移)

Phase 1: 原因特定 (read-only)

このフェーズではファイルの作成・編集・削除は一切行わないこと。

Step 1: 問題の把握・情報収集

• •ユーザーの報告から問題を正確に理解する
• •エラーメッセージ、ログ、スタックトレースなどを収集する
• •再現手順を確認する (可能であれば自分で再現する)

Step 2: 仮説の立案

最低 2 つの仮説を立てること。 1 つの仮説だけで調査を進めることは禁止。

仮説は以下の形式で明示する:

## 仮説

1. [仮説 1]: [具体的な原因の予想]
   - 根拠: [なぜそう考えるか]
   - 検証方法: [どうやって確認するか]

2. [仮説 2]: [具体的な原因の予想]
   - 根拠: [なぜそう考えるか]
   - 検証方法: [どうやって確認するか]

仮説を立てる観点:

• •コードの変更履歴 (最近何が変わったか)
• •入力データの異常
• •依存関係の変更
• •環境差異
• •競合状態やタイミングの問題

Step 3: 仮説の検証

複数の仮説は並列で検証する。 Task ツールで複数のサブエージェントを同時に起動し、各仮説を独立に検証する。

各サブエージェントには以下を指示する:

• •検証対象の仮説
• •検証手順
• •判定基準 (何が確認できたら仮説が正しい/間違いと判断するか)

Step 4: 原因の特定・報告

検証結果をまとめ、原因を報告する:

## 原因

[原因を 1-3 文で明確に述べる]

確信度: [高/中/低]

### 検証結果

- 仮説 1: [棄却/採択] - [理由]
- 仮説 2: [棄却/採択] - [理由]

### 根拠

[原因を裏付ける具体的な証拠 (コード箇所、ログ、再現結果など)]

Phase 2: 修正

原因が特定できたら、ユーザーに確認せず自動的に修正フェーズに移行する。

原則: main/master ブランチで直接修正しない。 /delegate-claude スキルで修正を委任する。

直接修正する例外:

• •dotfiles のように main で直接作業するリポジトリ
• •/delegate-claude によって worktree 内で動作している場合 (既に delegate 済み)

通常 (デフォルト)

/delegate-claude スキルで修正を委任する。プロンプトには以下を含めること:

• •背景: 発生している問題と原因
• •現状: 原因特定の調査結果
• •ゴール: 具体的な修正内容

例外: main で直接作業可能なリポジトリ

1. •修正を実装する
2. •テストがあれば実行して修正を検証する
3. •/commit スキルでコミットする

禁止事項 (Phase 1)

• •Edit, Write ツールの使用
• •Bash でのファイル操作 (作成、編集、削除)
• •git commit, git push などの変更を伴う操作