Resilience

Design and review how a scoped operation fails, sheds load, and recovers. Preserve business correctness before availability: a fast duplicate charge or a successful response for lost work is not resilient.

This Skill covers resilience policy and failure-evidence requirements. Adjacent concerns have their own stages and skills when loaded: architecture integration (backend-patterns or frontend-patterns), desired behavior (spec), the executable verification contract (plan), exploit paths (security-review), and the current implementation gate verdict (verification).

Workflow

1. Gate applicability and pin the failure boundary

Apply this Skill when failure crosses a remote dependency, durable queue or worker, multi-step side-effect boundary, or shared capacity limit. Ordinary local exceptions, error type design, response envelopes, user messages, and local async control flow are out of scope: stop with OUT OF SCOPE and name the concern the request actually belongs to — its skill, when loaded, is that concern's full procedure; a candidate still in processing is a PENDING pointer to its source path, never a pretend-available owner.

Inspect the relevant code, configuration, tests, and operational signals. Record:

• caller and dependency or producer and consumer;
• synchronous, asynchronous, scheduled, streaming, or mixed execution;
• side effects and the system that durably owns each one;
• caller latency budget, capacity limit, delivery guarantee, and recovery objective when known;
• existing timeout, cancellation, retry, queue, concurrency, and reconciliation controls.

Mark missing facts as assumptions. If side-effect ownership or the authoritative success condition cannot be established, return a blocked resilience assessment with the exact evidence needed; do not invent a policy.

Completion criterion: every affected boundary, side effect, and authoritative success signal is named or explicitly unresolved.

2. Classify attempts and outcomes

For each operation, classify:

• effect: read-only, naturally idempotent, idempotency-key guarded, conditionally safe, or non-idempotent;
• failure: transient, permanent, overload, deadline exhaustion, cancellation, malformed input, or unknown;
• outcome: confirmed success, confirmed failure, or unknown after a timeout, disconnect, worker death, or lost acknowledgement;
• duplication: impossible by contract, tolerated, deduplicated, or correctness-breaking.

A timeout bounds the caller's wait; it does not prove that remote work stopped. Treat every timed-out side-effecting attempt as unknown until a durable result, idempotency record, or reconciliation path resolves it.

Completion criterion: no retry or replay decision remains attached to an unclassified effect or outcome.

3. Set budgets before controls

Define one end-to-end deadline and allocate remaining time across attempts. State how cancellation propagates and what happens when the downstream operation cannot be cancelled. Bound retries by elapsed time and attempt count. Bound queued work by capacity and age.

Read Failure budgets and retries when the change waits on a remote dependency or may repeat an attempt.

Completion criterion: waiting, retrying, and queueing each have an observable upper bound stated as a chosen policy value or an inherited default, or the assessment names the missing owner who must choose it.

4. Select the smallest safe control set

Choose controls from the actual failure mode:

Read Load, isolation, and recovery for overload, circuit, backpressure, and partial-failure branches. Prefer the least complex set that preserves the invariant; keeping the current design is a candidate when evidence shows it already does so.

Completion criterion: every selected control names the failure it handles, its safety precondition, its cost, and why a simpler option is insufficient.

5. Map controls to enforcement points

Name the concrete call site, queue, transaction, worker, state record, or admission boundary that enforces each decision. Include propagation across layers: nested libraries, clients, service meshes, brokers, and workers can silently add retries or timeouts. Each bound chosen in step 3 also names the planning contract item that will observe it. When the plan has no such item, report that gap to the planning owner rather than supplying a value locally.

Route adjacent concerns without absorbing them:

Resilience consumes error signals from those concerns; it does not create a universal error hierarchy or response envelope.

Completion criterion: each policy has exactly one enforcement point in the system, every adjacent concern above is routed to its skill when loaded or recorded as PENDING, and aggregate attempts and deadlines across layers are accounted for.

6. Define failure-evidence requirements

Read Failure evidence. Select scenarios that must prove the scoped invariant, including the recovery path rather than only initial rejection. Prefer deterministic fakes or controllable test dependencies; require explicit authority and blast-radius controls for production fault injection.

For pre-implementation design, pass these evidence requirements to the planning stage — its executable verification contract (plan when loaded). For review of an existing implementation, pass commands or procedures, observations, expected signals, scope, assumptions, and worktree state to the verification stage (verification when loaded). This Skill may report design gaps; it does not issue READY, NOT READY, or BLOCKED for the implementation.

Completion criterion: every claimed control has a required failure scenario, an observable expected result, and a named downstream stage.

Output Contract

Assessment status: COMPLETE | BLOCKED | OUT OF SCOPE (resilience assessment only)
Boundary and invariant
Operation and outcome classification
Budgets and capacity bounds (value, source: chosen policy or inherited default, enforcement point)
Current controls
Selected controls and enforcement owners
Rejected alternatives and costs
Partial-failure and recovery path
Failure-evidence requirements
Assumptions, unresolved facts, and required owners
Verification handoff: PENDING | <existing fresh report reference>

A clean assessment is valid. Report it only after the failure-evidence contract covers the affected boundaries; do not manufacture controls or findings.

Guardrails

• Repeat a side-effecting operation only when idempotency or reconciliation makes the unknown outcome safe.
• Keep one retry owner per call path; include library, proxy, mesh, broker, worker, and client attempts in the aggregate budget.
• Propagate remaining deadlines rather than resetting a full timeout at each layer.
• Bound buffers and concurrency; queueing is load storage, not load removal.
• Define fallback correctness and freshness before calling degradation successful.
• Treat circuit breakers, retries, and queues as stateful operational mechanisms with metrics and recovery behavior, not decorators.