Debug

---
name: "debug"
description: "エラーや不具合を、ログ・再現・コードの実測から根本原因を特定して修正する。症状、スタックトレース、エラーログがある調査に使う。`--deepplan` は診断計画を深める明示オプション。"
argument-hint: "[症状やエラーメッセージ] [--deepplan]"
---

# Debug — 実測 → 原因特定 → 修正 → 確認

**症状**: $ARGUMENTS

親（main）はユーザーとの対話、再現条件、根本原因、修正範囲、計画、所有境界、受入、最終判断を持つ。実装担当の自己申告、終了コード、エラーメッセージだけで原因や完了を決めない。読み込んだこのスキルの同梱参照を使う場合も、対象リポジトリ内の同名パスや特定ランタイムのホームディレクトリを仮定せず、実体から解決する。

## Review/test の接続

レビューまたはテストが必要な場合、同じ親が shared skill package の実体にある `../reviewer/SKILL.md` または `../tester/SKILL.md` を存在確認して読み込み、その手順を実行する。別の進行担当を起動せず、親は症状、対象版、要件、ユーザー指定、実在する差分・再現結果、必要な確認範囲を渡し、選定・配分・集約は shared skill に委ねる。

shared reviewer は評価者へ `code-review-guidance/SKILL.md` の実体絶対パスと対応する reference だけを渡し、reviewer の進行手順を評価者へ渡さない。shared tester は `tester/references/test-procedure.md` と結果契約の実体を実行担当へ渡す。親が自ら評価・検証する場合だけ、必要な専門手順を読む。この workflow では観点、未知指定、担当間の分離、判定規則を再定義しない。

## 1. 症状を実測する

推測を重ねる前に、既存ログ、エラー出力、再現コマンド、失敗テスト、現在の status/diff、関連設定とコードを確認する。再現できる場合は、失敗条件と期待結果を記録する。外部仕様や更新され得る挙動は、利用可能な一次資料で裏取りする。

小さく局所的な症状は親が直接調査する。複数の独立領域、長い呼び出し経路、外部仕様の裏取りが必要なら、具体的な問いごとに現在のランタイムの委譲機構で read-only explorer を使う。探索担当には対象、既知の症状、確認済み事実、禁止範囲を渡し、実装・計画変更・リポジトリ状態の変更をさせない。レポートは後続の判断に必要な場合だけ作り、未生成のレポートパスを必須入力にしない。

開始時から存在するユーザーまたは他担当の変更は保全する。所有範囲外の差分を戻さない。`reset`、`checkout`、`restore`、`stash`、自動的な revert、commit、push は、ユーザーが明示した範囲を除き行わない。

## 2. 根本原因と修正条件を確定する

親がログ、再現結果、対象コード、探索結果を照合し、編集前に次を確定する。

- 失敗している層と、症状に至る呼び出し経路
- 根本原因と、それを示す `file:line` またはコマンド出力
- 成功条件と、変更前に失敗する再現確認
- 対象範囲、禁止範囲、修正候補のコストとリスク
- 根本原因に対応する最小修正と、その回帰確認

診断が未確定なら追加観測へ戻る。再現できないという理由だけで防御コード、例外握り潰し、retry、skip を追加しない。入力不足、環境、権限、外部サービスの問題は、実測した不足として切り分け、能力不足の仮説で別経路へ迂回しない。

`--deepplan` が明示された場合だけ deepplan スキルを読み込み、結果を親が実測結果と対象コードに照合する。指定がなければ親が必要な粒度の診断計画を持つ。長時間 run で再開情報が必要な場合や、ユーザーが記録を求めた場合だけ計画・handoff artifact を作る。handoff の作成・再開判定・更新・保管は shared skill package の `../pir2/references/handoff.md` に従う。再開時に親から実在する plan または handoff path が渡された場合は、その実体を読み、完了済み・決定済みの項目を保持したまま未完了項目だけを同じ path へ増分更新する。path を推測したり、未指定の artifact を作ったりしない。計画担当を必須化せず、親が計画を保持する。

## 3. リスクと権限を確認する

キーワードや変更ファイル数だけで固定工程を発火させず、変更による具体的な損害可能性から確認を選ぶ。

- 低リスク: 局所ロジック、文書、非実行設定。対象 diff と再現または focused check で判定できる。
- 中リスク: 公開挙動、複数モジュール、API、生成物、永続化形式。影響する境界の review または test を追加する。
- 高リスク・破壊的: データ損失、認証・認可、秘密情報、OS 権限、security control、schema migration、互換性破壊、本番・外部状態、広い生成連鎖。危険に対応する独立 review と実動作確認を計画し、復旧方法を確認する。

OS 設定、security control、認証・権限、本番・外部状態、不可逆操作、権限拡張を変更する場合は、対象、影響、復旧方法を提示して必要な明示承認を得る。承認を reviewer/tester の固定人数や形式の調整に置き換えない。

## 4. 実装と受入

親が診断、所有範囲、終了条件を確定してから実装経路を選ぶ。全体文脈と密結合した小修正は親が直接実装し、独立した通常修正はランタイムの worker/collaboration primitive、原因推論・状態・競合・性能が中心の難所は利用可能な高推論担当へ委譲できる。委譲時は症状、確認済み原因、許可・禁止範囲、維持する制約、終了条件、再現・回帰確認を短く渡す。担当が別担当を勝手に起動したり、scope を拡張したりしない。

実装後、親が status、対象 diff、実在する変更ファイルを確認し、元の再現または同等の確認で症状が解消したこと、根本原因に対応する focused regression を確認する。要求した確認、未実行の確認、環境・権限 blocker を分ける。返却文章や終了コードだけを受入根拠にしない。

## 5. レビューとテスト

親は前節の shared reviewer/tester に、診断、実在する差分、要件、再現結果、必要な確認範囲を渡す。返却された実在の結果を受入判断へ使い、観点の選定・配分・判定規則をこの workflow で複製しない。

テストは変更した挙動と防ぐ実害から選ぶ。プロジェクトの必須検証、再現・回帰、静的・構文・設定、必要な利用側・生成整合性を含める。フルスイートは影響範囲またはプロジェクト規約が必要とする場合だけ実行する。独立 tester が有効なら使い、実装担当の自己申告で代替しない。

reviewer/tester には実在する diff、診断、計画、受入条件だけを渡す。保存先が必要な場合だけ実行前に固有 path を決める。起動していない担当の verdict や未生成 artifact を作らない。

## 6. FAIL と再試行

reviewer/tester の FAIL は報告と実差分を照合し、再現可能な根本原因を特定して最小修正へ戻す。修正後は影響した観点と挙動だけを再確認し、無関係な PASS 済み確認を機械的に繰り返さない。同じ呼び出しが原因不明のまま続けて失敗した場合は3回目を試さず、実測した blocker と必要な判断を報告する。原因が特定され、変更で成功する合理的な根拠がある場合だけ再試行する。安全性、正しさ、権限、データ損失に関わる未確認事項が残る場合は完了扱いにしない。

## 7. 完了報告

```markdown
## Debug 完了サマリー

- 症状と再現条件: [実測結果]
- 根本原因: [file:line またはログ根拠]
- 変更ファイル: [実差分で確認した一覧]
- 確認: [実行したコマンドと結果]
- reviewer / tester: [実際に起動した担当と結果。未実行ならその理由]
- 未確認事項・blocker: [なければ none]
```

実行していない担当、存在しない report path、推測の原因を補完しない。