error-recovery
Strategies for handling subagent failures with retry logic and escalation patterns.
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o error-recovery.zip https://jpskill.com/download/17956.zip && unzip -o error-recovery.zip && rm error-recovery.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/17956.zip -OutFile "$d\error-recovery.zip"; Expand-Archive "$d\error-recovery.zip" -DestinationPath $d -Force; ri "$d\error-recovery.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
error-recovery.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
error-recoveryフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
エラー回復 Skill
適切なリトライ戦略を用いて、サブエージェントの失敗を適切に処理するためのパターンです。
この Skill をロードするタイミング
- 失敗する可能性のあるサブエージェントを生成している場合
- サブエージェントがエラーまたは予期しない出力を返した場合
- リトライ、エスカレーション、または中止のいずれかを決定する必要がある場合
失敗のカテゴリ
| カテゴリ | 症状 | 戦略 |
|---|---|---|
| 一時的 | タイムアウト、不正な形式の出力、解析エラー | 単純なリトライ |
| コンテキストのギャップ | 「十分な情報がない」、「不明確なタスク」 | コンテキストの強化 |
| 複雑さ | 部分的な完了、スコープの拡大、脱線 | スコープの縮小 |
| 境界/契約 | status: blocked、boundary_violation、contract_change |
エスカレーション |
| 致命的 | 繰り返しの失敗 (3回以上)、根本的な誤解 | レポートとともに中止 |
リトライ戦略
戦略 1: 単純なリトライ
一時的な失敗の場合。同じプロンプトで、最大3回試行します。
# 試行回数を追跡
attempts: 0
max_attempts: 3
# 失敗時
IF attempts < max_attempts:
attempts += 1
Task(same_subagent_type, same_model, same_prompt)
ELSE:
FAILED としてマークし、次に進む
使用するタイミング:
- 出力が不正な形式であるか、切り捨てられた場合
- タイムアウトが発生した場合
- エージェントが空/null の応答を返した場合
戦略 2: コンテキストの強化
エージェントが成功するのを助けるため、より多くの情報を追加します。
Task(
subagent_type: "implementer",
model: "sonnet",
prompt: |
## PREVIOUS ATTEMPT FAILED
Error: {error_message}
Output received: {partial_output}
## ADDITIONAL CONTEXT
Here is more information that may help:
- Related file: @{additional_file_path}
- Pattern to follow: {example_pattern}
- Specific guidance: {clarification}
## ORIGINAL TASK
{original_task_description}
Output to: {output_path}
)
使用するタイミング:
- エージェントが「理解できない」または「不明確な要件」と言った場合
- エージェントが誤った仮定をした場合
- エージェントが出力で質問をした場合
追加するコンテキスト:
- エージェントが必要とする可能性のある関連するコードファイル
- 例としての同様の実装
- 曖昧な点の明確な説明
- 前回の試行からのエラーメッセージ
戦略 3: スコープの縮小
失敗しているタスクを、より小さく、より管理しやすい部分に分割します。
# 元のタスクが失敗
Task: "Implement full authentication system"
# サブタスクに分割
Task(implementer, "Implement password hashing utility")
Task(implementer, "Implement session token generation")
Task(implementer, "Implement login endpoint")
Task(implementer, "Implement logout endpoint")
使用するタイミング:
- エージェントが部分的な作業を完了してから失敗した場合
- タスクの説明が広すぎた場合
- エージェントが脱線した場合
- 出力がスコープに関する混乱を示している場合
分割のガイドライン:
- 各サブタスクは独立して完了できる必要があります
- 各サブタスクは明確な境界を持つ必要があります
- サブタスクに依存関係がない場合は、並行して実行できます
- すべてのサブタスクが完了した後に出力を再結合します
戦略 4: エスカレーション
解決のために、専門のエージェントにルーティングします。
# 境界違反の場合
Task(
subagent_type: "contract-resolver",
model: "sonnet",
prompt: |
A task is blocked due to boundary/contract issues.
Blocked task output: memory/tasks/{task_id}/output.json
Blocked reason: {blocked_reason}
Current contracts: {contract_paths}
Analyze impact and provide resolution.
Output to: memory/contracts/resolution_{task_id}.json
)
エスカレーションパス:
| 失敗の種類 | エスカレーション先 | アクション |
|---|---|---|
blocked_reason: boundary_violation |
contract-resolver | 境界を拡大するか、再設計する |
blocked_reason: contract_change |
contract-resolver | 契約を変更し、依存関係を再検証する |
blocked_reason: dependency_issue |
executor (self) | 依存関係の状態を再確認する |
| 繰り返しの実装の失敗 | architect | 設計アプローチを再検討する |
戦略 5: レポートとともに中止
回復が不可能な場合は、適切に失敗します。
{"tasks":[{"id":"{task_id}","status":"failed","failure_reason":"{specific reason}","attempts_made":3,"recovery_attempted":[{"strategy":"simple_retry","result":"same_error"},{"strategy":"context_enhancement","result":"different_error"},{"strategy":"scope_reduction","result":"subtasks_also_failed"}],"recommendation":"Task may need architectural redesign"}]}
使用するタイミング:
- 3回以上のリトライ試行が失敗した場合
- 異なる戦略がすべて失敗した場合
- 要件の根本的な誤解
- タスクが制約を考えると実際には不可能である場合
決定木
サブエージェントの失敗時:
│
├─ 出力が不正な形式/空/タイムアウトですか?
│ └─ YES → 戦略 1: 単純なリトライ (最大3回)
│
├─ エージェントが「不明確」と言ったか、質問をしましたか?
│ └─ YES → 戦略 2: コンテキストの強化
│
├─ エージェントが部分的な作業を完了しましたか?
│ └─ YES → 戦略 3: スコープの縮小
│
├─ ステータスが境界/契約の理由で「blocked」ですか?
│ └─ YES → 戦略 4: contract-resolver へのエスカレーション
│
├─ すでに3つ以上の戦略を試しましたか?
│ └─ YES → 戦略 5: レポートとともに中止
│
└─ 不明なエラー
└─ まず戦略 2 を試し、次にエスカレーションする
リトライ状態の追跡
実行状態ファイルでリトライ試行を追跡します。
{"tasks":[{"id":"task-001","status":"running","attempts":2,"last_error":"Timeout after 120s","retry_strategy":"simple_retry"},{"id":"task-002","status":"running","attempts":1,"last_error":"Needs access to src/config/db.ts","retry_strategy":"context_enhancement","context_added":["src/config/db.ts","src/types/config.ts"]}]}
Executor ループとの統合
# 強化された実行ループ
WHILE タスクが未完了のままの場合:
1. 状態ファイルを読み取る
2. 準備完了のタスクを見つける
3. 準備完了のタスクを生成する
4. 完了したタスクを確認する:
FOR 各完了したタスクについて:
IF status == pre_complete:
verifier を生成する
ELIF status == blocked:
戦略 4 (エスカレーション) を適用する
ELIF status == failed:
determine_failure_category()
適切な戦略を適用する
retry_state() を更新する
5. 状態ファイルを更新する
6. IF すべて検証済み: EXIT
7. IF すべてが回復せずに失敗: EXIT wi
(原文がここで切り詰められています) 📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Error Recovery Skill
Pattern for handling subagent failures gracefully with appropriate retry strategies.
When to Load This Skill
- You are spawning subagents that may fail
- A subagent returned an error or unexpected output
- You need to decide whether to retry, escalate, or abort
Failure Categories
| Category | Symptoms | Strategy |
|---|---|---|
| Transient | Timeout, malformed output, parsing error | Simple Retry |
| Context Gap | "I don't have enough information", unclear task | Context Enhancement |
| Complexity | Partial completion, scope creep, tangents | Scope Reduction |
| Boundary/Contract | status: blocked, boundary_violation, contract_change |
Escalation |
| Fatal | Repeated failures (3+), fundamental misunderstanding | Abort with Report |
Retry Strategies
Strategy 1: Simple Retry
For transient failures. Same prompt, up to 3 attempts.
# Track attempts
attempts: 0
max_attempts: 3
# On failure
IF attempts < max_attempts:
attempts += 1
Task(same_subagent_type, same_model, same_prompt)
ELSE:
Mark as FAILED, move on
Use when:
- Output was malformed or truncated
- Timeout occurred
- Agent returned empty/null response
Strategy 2: Context Enhancement
Add more information to help the agent succeed.
Task(
subagent_type: "implementer",
model: "sonnet",
prompt: |
## PREVIOUS ATTEMPT FAILED
Error: {error_message}
Output received: {partial_output}
## ADDITIONAL CONTEXT
Here is more information that may help:
- Related file: @{additional_file_path}
- Pattern to follow: {example_pattern}
- Specific guidance: {clarification}
## ORIGINAL TASK
{original_task_description}
Output to: {output_path}
)
Use when:
- Agent said "I don't understand" or "unclear requirements"
- Agent made incorrect assumptions
- Agent asked questions in output
Context to add:
- Related code files the agent might need
- Similar implementations as examples
- Explicit clarification of ambiguous points
- Error message from previous attempt
Strategy 3: Scope Reduction
Break the failing task into smaller, more manageable pieces.
# Original task failed
Task: "Implement full authentication system"
# Split into subtasks
Task(implementer, "Implement password hashing utility")
Task(implementer, "Implement session token generation")
Task(implementer, "Implement login endpoint")
Task(implementer, "Implement logout endpoint")
Use when:
- Agent completed partial work then failed
- Task description was too broad
- Agent went off on tangents
- Output shows confusion about scope
Splitting guidelines:
- Each subtask should be independently completable
- Each subtask should have clear boundaries
- Subtasks can run in parallel if no dependencies
- Recombine outputs after all subtasks complete
Strategy 4: Escalation
Route to specialized agent for resolution.
# For boundary violations
Task(
subagent_type: "contract-resolver",
model: "sonnet",
prompt: |
A task is blocked due to boundary/contract issues.
Blocked task output: memory/tasks/{task_id}/output.json
Blocked reason: {blocked_reason}
Current contracts: {contract_paths}
Analyze impact and provide resolution.
Output to: memory/contracts/resolution_{task_id}.json
)
Escalation paths:
| Failure Type | Escalate To | Action |
|---|---|---|
blocked_reason: boundary_violation |
contract-resolver | Expand boundaries or redesign |
blocked_reason: contract_change |
contract-resolver | Modify contract, re-verify dependents |
blocked_reason: dependency_issue |
executor (self) | Re-check dependency status |
| Repeated implementation failures | architect | Reconsider design approach |
Strategy 5: Abort with Report
When recovery is not possible, fail gracefully.
{"tasks":[{"id":"{task_id}","status":"failed","failure_reason":"{specific reason}","attempts_made":3,"recovery_attempted":[{"strategy":"simple_retry","result":"same_error"},{"strategy":"context_enhancement","result":"different_error"},{"strategy":"scope_reduction","result":"subtasks_also_failed"}],"recommendation":"Task may need architectural redesign"}]}
Use when:
- 3+ retry attempts failed
- Different strategies all failed
- Fundamental misunderstanding of requirements
- Task is actually impossible given constraints
Decision Tree
On Subagent Failure:
│
├─ Is output malformed/empty/timeout?
│ └─ YES → Strategy 1: Simple Retry (up to 3x)
│
├─ Did agent say "unclear" or ask questions?
│ └─ YES → Strategy 2: Context Enhancement
│
├─ Did agent complete partial work?
│ └─ YES → Strategy 3: Scope Reduction
│
├─ Is status "blocked" with boundary/contract reason?
│ └─ YES → Strategy 4: Escalation to contract-resolver
│
├─ Have we tried 3+ strategies already?
│ └─ YES → Strategy 5: Abort with Report
│
└─ Unknown error
└─ Try Strategy 2 first, then escalate
Retry State Tracking
Track retry attempts in the execution state file:
{"tasks":[{"id":"task-001","status":"running","attempts":2,"last_error":"Timeout after 120s","retry_strategy":"simple_retry"},{"id":"task-002","status":"running","attempts":1,"last_error":"Needs access to src/config/db.ts","retry_strategy":"context_enhancement","context_added":["src/config/db.ts","src/types/config.ts"]}]}
Integration with Executor Loop
# Enhanced execution loop
WHILE tasks remain incomplete:
1. Read state file
2. Find ready tasks
3. Spawn ready tasks
4. Check completed tasks:
FOR each completed task:
IF status == pre_complete:
spawn verifier
ELIF status == blocked:
apply Strategy 4 (Escalation)
ELIF status == failed:
determine_failure_category()
apply_appropriate_strategy()
update_retry_state()
5. Update state file
6. IF all verified: EXIT
7. IF all failed with no recovery: EXIT with failure report
Principles
- Fail fast, recover smart - Don't retry blindly; analyze the failure first
- Preserve partial work - If agent completed 50%, don't discard it
- Escalate early - Boundary/contract issues need resolver, not retries
- Track everything - Log all attempts for reflection phase
- Know when to quit - 3 failed strategies = abort, don't loop forever