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

症状: $ARGUMENTS

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

1. 症状を実測する

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

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

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

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

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

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

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

修正に実装全体へ波及する設計判断が必要なら、同じshared packageの PIR²の専門検討から実装条件へ を読み、必要な観点だけを条件・根拠・確認方法へまとめる。診断ですでに確定した原因や条件は再利用し、明確な局所修正へ専門担当を追加しない。委譲・再修正時は implementation-delegation.md の受け渡しを使う。

--deepplan が明示された場合だけ deepplan スキルを読み込み、結果を親が実測結果と対象コードに照合する。指定がなければ親が必要な粒度の診断計画を持つ。長時間 run で再開情報が必要な場合や、ユーザーが記録を求めた場合だけ計画・handoff artifact を作る。handoff の作成・再開判定・更新・保管は shared skill package の ../pir2/references/handoff.md に従う。計画担当を必須化せず、親が計画を保持する。

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

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

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

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

4. 実装と受入

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

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

5. レビューとテスト

親は shared reviewer/tester に診断、実在する差分、要件、再現結果、必要な確認範囲を渡す。レビューは shared reviewer の手順で独立した評価担当が行い、親自身の評価で代替しない。返却された実在の結果を受入判断へ使い、観点の選定・配分・判定規則をこの workflow で複製しない。

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

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

6. FAIL と再試行

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

7. 完了報告

## Debug 完了サマリー

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

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