Agent Introspection Debugging

エージェント実行が繰り返し失敗し、トークンを消費しているのに進捗がない、同じツールをループしている、または意図したタスクから外れている場合にこのスキルを使用してください。

これはランタイムの隠し機能ではなく、ワークフロースキルです。エージェントが人間にエスカレートする前に体系的に自己デバッグを行うようにトレーニングします。

アクティベーション時機

• ツール呼び出し / ループ制限の最大失敗
• 進捗のない繰り返しの再試行
• 出力品質を低下させ始めるコンテキスト増加またはプロンプトドリフト
• 予期と実際の間のファイルシステムまたは環境状態の不一致
• 診断と小規模な修正アクションで回復可能性が高いツール障害

スコープの境界

以下の場合にこのスキルをアクティベートします：

• 盲目的に再試行する前に障害状態をキャプチャする
• 一般的なエージェント固有の障害パターンを診断する
• 制限された回復アクションを適用する
• 構造化された人間が読める形式のデバッグレポートを生成する

以下の場合はこのスキルを主要な情報源として使用しないでください：

• コード変更後の機能検証；verification-loop を使用してください
• より狭い ECC スキルが既に存在する場合のフレームワーク固有のデバッグ
• 現在のハーネスが自動的に強制できないランタイムプロミス

4段階ループ

Phase 1: 障害キャプチャ

回復を試みる前に、障害を正確に記録します。

キャプチャするもの：

• エラー型、メッセージ、利用可能な場合はスタックトレース
• 最後の意味のあるツール呼び出しシーケンス
• エージェントが何をしようとしていたか
• 現在のコンテキスト圧力：繰り返されるプロンプト、オーバーサイズの貼り付けログ、複製されたプラン、または暴走ノート
• 現在の環境の前提：cwd、ブランチ、関連するサービス状態、予期されるファイル

最小キャプチャテンプレート：

## Failure Capture
- Session / task:
- Goal in progress:
- Error:
- Last successful step:
- Last failed tool / command:
- Repeated pattern seen:
- Environment assumptions to verify:

Phase 2: 根本原因診断

何かを変更する前に、障害を既知のパターンと照合します。

パターン	考えられる原因	チェック内容
最大ツール呼び出し / 同じコマンドの繰り返し	ループまたは出口なしのオブザーバーパス	最後の N 個のツール呼び出しを検査して繰り返しを確認
コンテキストオーバーフロー / 推論の低下	無制限のノート、繰り返されるプラン、オーバーサイズログ	最近のコンテキストを検査して複製と低シグナルバルクを確認
ECONNREFUSED / タイムアウト	サービス利用不可またはポート誤り	サービス状態、URL、ポート前提を確認
429 / クォータ枯渇	リトライストームまたは欠落バックオフ	繰り返し呼び出しをカウントしてリトライ間隔を検査
書き込み後のファイル欠落 / 古い差分	レース、cwd 誤り、またはブランチドリフト	パス、cwd、git ステータス、実際のファイル存在を再確認
「修正」後も失敗するテスト	仮説が間違っている	正確に失敗しているテストを分離して、バグを再導出

診断質問：

• これは論理障害、状態障害、環境障害、またはポリシー障害か？
• エージェントが実際の目標を失って、間違ったサブタスクを最適化し始めたか？
• 障害は決定論的か一時的か？
• 診断サーフェスを検証する最小の可逆アクションは何か？

Phase 3: 制限された回復

診断サーフェスを変更する最小アクションで回復します。

安全な回復アクション：

• 繰り返しの再試行を停止して仮説を再述する
• 低シグナルコンテキストをトリムして、アクティブな目標、ブロッカー、証拠のみを保持する
• 実際のファイルシステム / ブランチ / プロセス状態を再チェックする
• タスクを1つの失敗コマンド、1つのファイル、または1つのテストに絞る
• 推測的推論から直接観察に切り替える
• 障害が高リスクまたは外部でブロックされている場合は人間にエスカレートする

現在の環境の実際のツールを通じて実際に実行していない限り、「エージェント状態をリセット」または「ハーネス設定を更新」などのサポートされていない自動修復アクションを主張しないでください。

制限された回復チェックリスト：

## Recovery Action
- Diagnosis chosen:
- Smallest action taken:
- Why this is safe:
- What evidence would prove the fix worked:

Phase 4: 内省レポート

次のエージェントまたは人間に回復を分かりやすくするレポートで終了します。

## Agent Self-Debug Report
- Session / task:
- Failure:
- Root cause:
- Recovery action:
- Result: success | partial | blocked
- Token / time burn risk:
- Follow-up needed:
- Preventive change to encode later:

回復ヒューリスティック

以下の順序で介入を優先してください：

1. 実際の目標を1文で再述する。
2. メモリを信頼する代わりに世界の状態を検証する。
3. 失敗スコープを縮小する。
4. 1つの識別チェックを実行する。
5. その後で再試行する。

悪いパターン：

• わずかに異なる文言で同じアクションを3回再試行する

良いパターン：

• 障害をキャプチャ
• パターンを分類
• 1つの直接チェックを実行
• チェックが支持する場合のみプランを変更

ECC との統合

• コードが変更された場合、回復後に verification-loop を使用します。
• 障害パターンが本能または後のスキルに変える価値がある場合、continuous-learning-v2 を使用します。
• 問題が技術的な障害ではなく決定の曖昧性である場合、council を使用します。
• 障害がローカル状態の競合またはリポジトリドリフトから生じた場合、workspace-surface-audit を使用します。

出力標準

このスキルがアクティベートされている場合、「修正しました」だけで終了しないでください。

常に以下を提供します：

• 障害パターン
• 根本原因の仮説
• 回復アクション
• 状況がより良くなったか、それでもブロックされているかの証拠