resilient-execution

概要

resilient-execution スキルは、ユーザーにエスカレーションする前に、実質的に異なるアプローチを最低 3 つ試すことを徹底し、早まった失敗を防ぎます。体系的なエラー分類システム、アプローチを順に試す方法、各試行の透明性の高い記録を提供します。このスキルがない場合、エージェントは早々に諦めてしまいます。このスキルがあれば、代替策を体系的に試し尽くし、十分な証拠をそろえたうえでのみエスカレーションできます。

開始時に次のように伝えます：「resilient-execution スキルを使用します。エスカレーションする前に、複数のアプローチを試します。」

---

フェーズ 1：エラーの分類

アプローチが失敗したら、再試行する前に、ただちにエラーを分類します。

エラーの種類	定義	判断材料	適切な対応
一時的	一時的なインフラストラクチャの障害	ネットワークのタイムアウト、レート制限、503 エラー、ロックの競合	少し待って、同じアプローチを再試行します
環境的	依存関係の不足または設定ミス	モジュールが見つからない、バージョン違い、環境変数の不足、アクセス権限の拒否	環境を修正してから、同じアプローチを再試行します
論理的	アプローチの誤り、または前提の誤り	出力の誤り、予期しない動作、型の不一致、API の誤った使用方法	アプローチを全面的に見直します
根本的	利用可能なツールでは本当に実現できない	API が存在しない、ハードウェアの制限、機能が不足している	証拠を添えてユーザーにエスカレーションします

何かができないとユーザーに伝える前に、少なくとも 3 つの異なるアプローチを試す必要があります。実質的に異なる戦略で 3 回試みた証拠がない状態で「試しましたが、うまくいきませんでした」と伝えることは認められません。

停止：次のアプローチを選ぶ前に、エラーを分類してください。誤った分類は、無駄な再試行につながります。

---

フェーズ 2：アプローチのカスケード

カスケードを体系的に実行します。各試行では、実質的に異なる戦略を使う必要があります。

Attempt 1: Primary approach (most direct solution)
    | fails
    v
Classify error -> Can same approach work with a fix?
    | YES -> Fix and retry (does NOT count as a new attempt)
    | NO  -> Proceed to Attempt 2
    v
Attempt 2: Alternative approach 1 (different technique)
    | fails
    v
Classify error -> Is this fundamentally blocked?
    | YES -> Proceed directly to escalation
    | NO  -> Proceed to Attempt 3
    v
Attempt 3: Alternative approach 2 (different path entirely)
    | fails
    v
Circuit breaker -> Present findings to user with full evidence

各試行で記録する内容：

### Attempt N: [Approach Name]
**Strategy:** [what makes this different from previous attempts]
**What I tried:** [specific description with commands/code]
**What happened:** [exact error or unexpected result]
**Why it failed:** [root cause analysis]
**Classification:** [Transient / Environmental / Logical / Fundamental]
**What to try next:** [reasoning for next approach]

停止：次の試行に進む前に、すべての試行を記録してください。記録を省略しないでください。エスカレーションレポートの証拠になります。

---

フェーズ 3：代替アプローチの選択

主なアプローチが失敗した場合は、次の判断表を使って次のアプローチを選択します。

失敗の種類	戦略 1	戦略 2	戦略 3
ライブラリ／API が動作しない	別のライブラリを使う	直接実装する（ライブラリを使わない）	シェルコマンド／外部ツールを使う
アルゴリズムが誤った結果を出す	別のアルゴリズムを使う	小さな手順に分解する	制約を簡略化し、より簡単なバージョンを解く
権限／アクセスが拒否される	別のアクセス方法を使う	手動の手順を示してエスカレーションする	別の経路で回避する
ツールの制限	別のツールを使う	複数のツールを組み合わせる	手動の手順を示す
統合の失敗	依存関係をモックする	代替インターフェースを使う	コンポーネントを個別に分離してテストする
パフォーマンスの問題	別のデータ構造を使う	バッチ処理／ストリーム処理を行う	近似解を使う

代替戦略の優先順位

次の順に試してください。

1. 別のツール — 別のライブラリ、API、またはコマンドを使います
2. 別のアルゴリズム — 同じ問題を別の方法で解きます
3. 分解する — 問題を、解決可能な小さな部分に分けます
4. 簡略化する — 制約を取り除き、まず簡単なバージョンを解きます
5. 別の方法で回避する — まったく別の経路で目標を達成します
6. 手動の手順 — ユーザーが自分で実行できる明確な手順を示します

---

フェーズ 4：エスカレーションレポート

異なるアプローチで実質的に 3 回試みた後、次のレポートを作成します。

## Execution Report

I tried 3 different approaches to [goal]:

### Attempt 1: [Approach Name]
**Strategy:** [description]
**Result:** Failed because [specific reason]
**Error:** [exact error message or unexpected output]

### Attempt 2: [Approach Name]
**Strategy:** [description]
**Result:** Failed because [specific reason]
**Error:** [exact error message or unexpected output]

### Attempt 3: [Approach Name]
**Strategy:** [description]
**Result:** Failed because [specific reason]
**Error:** [exact error message or unexpected output]

### Root Cause Analysis
[Why all three approaches failed — identify the common blocker]

### Recommended Next Steps
- **Option A:** [what the user could try]
- **Option B:** [alternative path]
- **Option C:** [if applicable]

### What I Need From You to Proceed
[Specific ask — access, information, permission, or decision]

停止：このレポートなしでエスカレーションしないでください。ユーザーには、実質的に 3 回試みたことを示す証拠が必要です。

---

判断表：「真の」試行として数える条件

真の試行として数える	数えない
異なるライブラリまたはツール	インポート方法だけが異なる同じライブラリ
異なるアルゴリズムまたはデータ構造	パラメーターを調整しただけの同じアルゴリズム
異なるアーキテクチャアプローチ	コードを少し変更しただけの同じアプローチ
自動化に対する手動の回避策	再試行ループを追加しただけの同じ自動化
問題をサブ問題に分割する	ログを追加しただけの同じモノリシックなアプローチ
まったく異なる API を使用する	認証方法だけが異なる同じ API（エラーの原因が認証だった場合を除く）

---

アンチパターン／よくある間違い

してはいけないこと	うまくいかない理由	代わりにすること
同じアプローチを 3 回再試行し、「3 回試した」とみなす	同じアプローチでは同じ失敗になります。真の代替案ではありません。	各試行では、実質的に異なる戦略を使用する必要があります
1 回失敗しただけで諦める	2 つ以上ある実行可能なアプローチを見逃します	常に、真に異なるアプローチを少なくとも 3 つ試してください
エラーの分類を省略する	分類しないと、間違ったことを再試行します	次のアプローチを選ぶ前に、必ず分類してください
失敗した試行をユーザーに隠す	コンテキストがなければ、ユーザーは支援できません	すべての試行を記録し、透明性をもって報告してください
手動の回避策を試さずにエスカレーションする	自動化では失敗することでも、手動ならうまくいく場合があります	常にアプローチ 3 として手動の手順を検討してください
調査せずにプラットフォームのせいにする	「プラットフォームの制限」は誤りであることがよくあります	不可能だと判断する前に、回避策を探してください
環境の問題を修正し、新しい試行として数える	環境を修正して同じアプローチを再試行するのは 1 回の試行です	真に異なる戦略だけを数えてください
中間の試行のログを省略する	証拠の記録が失われ、エスカレーションレポートを作成できません	すべての試行を直ちに記録してください

---

自己正当化を防ぐための指針

考え	現実
「これは本当に実現できない」	異なるアプローチを 3 つ試しましたか？おそらく試していません。
「エラーは明らかで、何が問題か分かっている」	明確なエラーにも、隠れた根本原因がある場合があります。調査してください。
「もうあらゆることを試した」	試したことを列挙してください。ほかにも常に選択肢があります。
「ユーザーが自分で直すべきだ」	手動での方法を提示しつつ、まず 3 つのアプローチを試してください。
「これはプラットフォームの制限だ」	制限には回避策があることがよくあります。探してください。
「同じエラーが繰り返し発生する」	異なるアプローチで同じエラーが出る場合、根本原因は異なります。分類してください。
「時間がかかりすぎている」	ユーザーが最初からやり直すことになれば、諦めるほうが時間がかかります。
「よりシンプルなバージョンでは役に立たない」	動かない複雑なものより、動くシンプルなもののほうが優れています。

真の試行を 3 回行うまでは、絶対にエスカレーションしないでください。

---

連携ポイント

スキル	関係
circuit-breaker	resilient-execution がループレベルで再試行を使い果たした後に有効になります
task-management	タスクのステップが失敗した際に resilient-execution を呼び出します
self-learning	今後のセッションで同じ失敗を繰り返さないよう、失敗パターンを記録します
planning	失敗履歴を使用して、より堅牢なアプローチを選択します
auto-improvement	再試行の成功率とアプローチの有効性を追跡します
verification-before-completion	検証に失敗した場合、resilient-execution を呼び出します

---

具体例

例：ファイル解析の失敗

Attempt 1: JSON.parse() on the file
  Result: SyntaxError — file contains comments (JSONC format)
  Classification: Logical — wrong parser for this format

Attempt 2: Strip comments with regex, then JSON.parse()
  Result: Failed — nested block comments not handled
  Classification: Logical — regex too simple for comment stripping

Attempt 3: Use `jsonc-parser` library (handles JSONC natively)
  Result: Success — file parsed correctly

例：API 統合の失敗

Attempt 1: Direct HTTP request to API endpoint
  Result: 403 Forbidden — authentication required
  Classification: Environmental — missing auth config

  Fix: Add API key from .env
  Result: 429 Too Many Requests — rate limited
  Classification: Transient — wait and retry
  Result: 200 OK but response format changed from docs
  Classification: Logical — API version mismatch

Attempt 2: Use official SDK instead of raw HTTP
  Result: SDK throws "unsupported region" error
  Classification: Environmental — region config needed

Attempt 3: Use GraphQL endpoint instead of REST
  Result: Success — GraphQL endpoint supports all regions

---

主な原則

• 黙って諦めない — 何を試したかを必ず示してください
• 真の代替案 — 各試行では、少し変更しただけの同じ方法ではなく、実質的に異なるアプローチを使用する必要があります
• 根本原因の分析 — 次のアプローチを試す前に、理由を理解してください
• 失敗から学ぶ — うまくいかなかったこととその理由をメモリに更新してください
• 透明性を保つ — 各ステップで、判断の根拠をユーザーに示してください
• まず分類する — エラーの種類によって、同じアプローチを再試行するか、新しいアプローチを試すかが決まります

---

スキルタイプ

RIGID — 3 回の試行という最低要件は、必ず満たさなければならないゲートです。再試行の前には、必ずエラーを分類してください。エスカレーション報告の形式には厳密に従ってください。簡単に見える場合でも、これらの要件を緩和してはいけません。