Resilient Execution

Overview

The resilient-execution skill prevents premature failure by enforcing a minimum of 3 genuinely different approaches before escalating to the user. It provides a structured error classification system, an approach cascade methodology, and transparent logging of each attempt. Without this skill, agents give up too early — with it, they systematically exhaust alternatives and only escalate with full evidence.

Announce at start: "I'm using the resilient-execution skill — I will try multiple approaches before escalating."

---

Phase 1: Error Classification

When an approach fails, immediately classify the error before retrying:

<HARD-GATE> You MUST try at least 3 different approaches before telling the user something cannot be done. "I tried and it didn't work" is not acceptable without evidence of 3 genuine attempts with meaningfully different strategies. </HARD-GATE>

STOP: Classify the error before choosing your next approach. Wrong classification leads to wasted retries.

---

Phase 2: Approach Cascade

Execute the cascade systematically. Each attempt must be a genuinely different strategy.

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

For Each Attempt, Log:

### 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]

STOP: Log every attempt before moving to the next. Do NOT skip logging — it is evidence for the escalation report.

---

Phase 3: Alternative Approach Selection

When the primary approach fails, select the next approach using this decision table:

Alternative Strategy Hierarchy

Try these in order of preference:

1. Different tool — use a different library, API, or command 2. Different algorithm — solve the same problem a different way 3. Decompose — break the problem into smaller, solvable parts 4. Simplify — remove constraints and solve a simpler version first 5. Work around — achieve the goal through a different path entirely 6. Manual steps — provide clear instructions the user can follow themselves

---

Phase 4: Escalation Report

After 3 genuine attempts with different approaches, produce this report:

## 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]

STOP: Do NOT escalate without this report. The user needs evidence that 3 genuine attempts were made.

---

Decision Table: When Retries Count as "Genuine"

---

Anti-Patterns / Common Mistakes

---

Anti-Rationalization Guards

Do NOT escalate without 3 genuine attempts. Period.

---

Integration Points

---

Concrete Examples

Example: File Parsing Failure

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

Example: API Integration Failure

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

---

Key Principles

• Never give up silently — always show what was tried
• Genuine alternatives — each attempt must be a meaningfully different approach, not the same thing with minor tweaks
• Root cause analysis — understand WHY before trying the next approach
• Learn from failure — update memory with what did not work and why
• Transparent — show the user your reasoning at each step
• Classify first — error type determines whether to retry same approach or try a new one

---

Skill Type

RIGID — The 3-attempt minimum is a HARD-GATE. Error classification is mandatory before each retry. The escalation report format must be followed exactly. Do not relax these requirements regardless of perceived simplicity.