القائمة
キャプチャ、診断、封じ込め回復、内省レポートを使用した AI エージェント障害のための構造化された自己デバッグワークフロー。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use this skill to monitor and verify a deployed URL or public OSS launch surface after releases — checks HTTP endpoints, SSE streams, static assets, console errors, performance regressions, PR queue health, maintainer feedback, and listing-review blockers after deploys, merges, submissions, or dependency upgrades. Smoke / canary / post-deploy / PR-watch verification.
Build reputation-safe open-source marketing from verifiable project evidence, not hype, spam, or repeated public pings. Use for launch copy, directory targeting, community posts, proof packets, and maintainer-facing positioning.
Turn public launch, directory, community, or list rejections into repo fixes and better proof without arguing, spamming, or resubmitting blindly. Use after Hacker News, Product Hunt, GitHub list PR, marketplace, or community rejection.
Structured self-debugging workflow for AI agent failures using capture, diagnosis, contained recovery, and introspection reports.
Build an evidence-backed ecc install plan for a specific repo by sorting skills, commands, rules, hooks, and extras into DAILY vs LIBRARY buckets using parallel repo-aware review passes. Use when ecc should be trimmed to what a project actually needs instead of loading the full bundle.
Build a source-derived writing style profile from real posts, essays, launch notes, docs, or site copy, then reuse that profile across content, outreach, and social workflows. Use when the user wants voice consistency without generic AI writing tropes.
| name | agent-introspection-debugging |
| description | キャプチャ、診断、封じ込め回復、内省レポートを使用した AI エージェント障害のための構造化された自己デバッグワークフロー。 |
| origin | ecc |
エージェント実行が繰り返し失敗している、進展なくトークンを消費している、同じツールをループしている、または意図したタスクから逸脱している場合にこのスキルを使用します。
これはワークフロースキルであり、隠れたランタイムではありません。エージェントが人間にエスカレーションする前に体系的に自己デバッグするよう教えます。
このスキルを起動するのは以下の場合：
このスキルを主なソースとして使用しない場合：
verification-loop を使用回復を試みる前に、障害を正確に記録します。
キャプチャ内容：
最小キャプチャテンプレート：
## 障害キャプチャ
- セッション / タスク:
- 進行中の目標:
- エラー:
- 最後に成功したステップ:
- 最後に失敗したツール / コマンド:
- 観察された繰り返しパターン:
- 検証すべき環境の前提:
何も変更する前に、障害を既知のパターンに照合します。
| パターン | 考えられる原因 | チェック |
|---|---|---|
| ツール呼び出しの最大数 / 同じコマンドの繰り返し | ループまたは出口なしのオブザーバーパス | 最後の N 回のツール呼び出しを繰り返しについて検査する |
| コンテキストオーバーフロー / 推論の低下 | 無制限のノート、繰り返される計画、過大なログ | 最近のコンテキストを重複と低シグナルのバルクについて検査する |
ECONNREFUSED / タイムアウト | サービスが利用不可または間違ったポート | サービスの健全性、URL、ポートの前提を確認する |
429 / クォータ枯渇 | リトライストームまたはバックオフなし | 繰り返し呼び出しを数え、リトライ間隔を検査する |
| 書き込み後にファイルが見つからない / 古い差分 | レース、間違った cwd、またはブランチドリフト | パス、cwd、git ステータス、実際のファイル存在を再確認する |
| 「修正」後もテストが失敗し続ける | 間違った仮説 | 失敗している正確なテストを分離し、バグを再導出する |
診断の質問：
診断の表面を変える最小のアクションで回復します。
安全な回復アクション：
現在の環境の実際のツールを通じて実際にそれらを行っていない限り、「エージェント状態をリセット」または「ハーネス設定を更新」のような自動回復アクションを主張しないこと。
封じ込め回復チェックリスト：
## 回復アクション
- 選択した診断:
- 取った最小アクション:
- なぜこれが安全か:
- 修正が機能したことを証明するエビデンスは何か:
次のエージェントや人間が回復を理解できるレポートで終了します。
## エージェント自己デバッグレポート
- セッション / タスク:
- 障害:
- 根本原因:
- 回復アクション:
- 結果: 成功 | 部分的 | ブロック中
- トークン / 時間の消費リスク:
- 必要なフォローアップ:
- 後でエンコードすべき予防的変更:
この順序で介入を優先する：
悪いパターン：
良いパターン：
verification-loop を使用する。continuous-learning-v2 を使用する。council を使用する。workspace-surface-audit を使用する。このスキルがアクティブな場合、「修正しました」だけで終わらないこと。
常に提供する：