Claude Skill

resilience-audit

Failure-mode audit (FMEA for software) — for each way the system can fail (network, storage, partial completion, crash, concurrency, bad input), check whether code DETECTS, HANDLES, RECOVERS, and COMMUNICATES it. Triggers on: "/resilience-audit", "resilience-audit", "FMEA audit".

LLM Mart · 0 points · 0 0 0

Virus-scanned Reviewed automatically before listing.

Full trust report

Download hetcreep-coalmine-skills_resilience-audit-85306d7.zip · 3 KB

hetcreep/coalmine 13 2 forks Apache-2.0 Updated 7d ago

Part of hetcreep/coalmine — 18 skills

Install

skills CLI npx skills add https://github.com/TheColliery/CoalMine/tree/main/skills/resilience-audit

Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install hetcreep-coalmine@llmmart

Git git clone https://github.com/TheColliery/CoalMine.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole hetcreep/coalmine collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Resilience Audit

For every operation: "what happens when this FAILS?" Report; do NOT fix unless asked.

Failure categories

External I/O — network down/slow, API 4xx/5xx/timeout, rate-limit. Retry w/ backoff? Timeout set? Clear error vs hang?
Storage — disk full, permission denied, partial write. Atomic write (temp+rename)? Cleanup on failure? Existing good copy untouched?
Partial completion — half-done op (50/100 files). Reported as FAILURE, never success.
Crash / OOM — killed mid-op. Idempotent restart? No orphaned half-state?
Concurrency — two instances, race, deadlock. Locking / idempotency / safe re-entry?
Input / data — malformed, null, truncated, huge. Validate at boundary? Fail-fast?
Dependency down — fallback/cache/graceful degrade? Clear error vs silent hang?
Resource exhaustion — bounded? Backpressure? Cleanup on error path?

Per-stack timeout/atomicity/idempotency patterns to grep: read references/checks.md before scanning.

For each failure point, check 4 things

Detected? code notices it (doesn't swallow)?
Handled? retry/fallback/fail-clean — not ignored, not silent-success?
Recoverable? rollback/idempotent; no data loss or corruption?
Communicated? clear error to user+log; not a hang, not a false "done"?

Discipline

Trace actual failure path (cite file:line). Don't assume handling exists; prove it.
"partial = failure" — any path reporting success on partial completion = CRITICAL.
"logged" ≠ "handled" — swallowed+logged error that corrupts state or returns success = CRITICAL.

Fix mode (choice-gated)

After the report, present via ask_question:

Fix safe ones — add missing timeout, null/input validation, clear error+log on unhandled path. Each: checkpoint → fix → build+tests → revert if newly red.
Let me pick — user-selected fixes only.
Report only — change nothing.

NEVER auto-fix: retry/rollback/recovery/atomicity logic (semantic changes can introduce new failure modes).

Grants & denials (CLASSIFY-BLOCK)

class	step it powers	grant	on denial
read	trace failure paths for the 8 categories above	`Read`·`Grep`·`Glob`	refuse that file, name it — never a clean bill
write	Fix mode's safe-guard apply, incl. checkpoint → build+tests → revert if newly red	`Edit`·`Bash` (checkpoint/build/revert need exec)	report the fix as NOT applied AND the checkpoint/revert as NOT available, never claim done

Output

Severity: CRITICAL (data loss/corruption/silent-success) · HIGH (crash/hang/partial-no-recovery) · MEDIUM (poor degradation/missing retry) · LOW (cosmetic)

Files (coalmine)

references

checks.md 2.6 KB

<!-- coalmine: verified 2026-06-12 · revalidate 90d · definition file for resilience-audit -->
# Resilience audit — concrete detection procedures

## 1. External I/O — what to grep
| Stack | Missing timeout looks like | Right shape |
|---|---|---|
| TS/JS | bare `fetch(url)` / axios without `timeout` | `AbortSignal.timeout(ms)` / axios `timeout` |
| C# | `HttpClient` with default (100 s) timeout in hot paths | per-request `CancellationTokenSource` |
| Python | `requests.get(url)` with no `timeout=` (waits forever) | explicit `timeout=(connect, read)` |
| Go | `http.Get` (no deadline) | `http.Client{Timeout}` / `context.WithTimeout` |
Retry without backoff/jitter or without a max-attempts bound = finding (retry storms). Rate-limit responses (429) swallowed as generic errors = finding.

## 2. Storage — atomicity
- Safe write idiom: write temp file → fsync → rename over target. Direct `writeFile(target)` on data the app must not lose = finding (crash mid-write corrupts).
- Error path must clean partial output; the previous good copy must survive failure (never delete-then-write).

## 3. Partial completion
- Any loop over N items that catches per-item errors and then reports unconditional success = CRITICAL ("extracted 50/100, said done").
- Right shape: count failures, surface `n/N (k failed)`, non-zero exit / failure status on k>0.

## 4. Crash / restart idempotency
- Re-running the operation after a kill must not duplicate effects (payments, sends, appends). Look for: append-without-dedup, missing idempotency keys on external calls, half-state files without a journal/marker.

## 5. Concurrency
- Two instances racing on the same file/row: look for check-then-act gaps (`existsSync` → `writeFile`), missing locks/transactions, TOCTOU on temp paths.

## 6. Input boundary
- Malformed/huge/truncated input at every parse site: `JSON.parse` without try, unbounded `readFile` of attacker-sized payloads, missing schema validation at process edges. Fail fast with the exact reason; never half-apply.

## 7. Dependency down
- For each external service: what happens on ECONNREFUSED? Acceptable answers: cached fallback, graceful degrade, clear error. Unacceptable: hang, retry-forever, silent empty result presented as truth.

## 8. Resource exhaustion
- Unbounded queues/buffers fed by external input; connections acquired without release on the error path; missing backpressure on producers.

## The four-question check (every failure point)
Detected? (code notices, doesn't swallow) · Handled? (retry/fallback/fail-clean) · Recoverable? (rollback/idempotent, no data loss) · Communicated? (clear error to user AND log — never a false "done").

skill-meta.json 181 B

{ "lightIntent": "Spot failure-mode check, key paths only", "standardIntent": "Balanced FMEA, multi-category coverage", "heavyIntent": "Full 8-category FMEA + adversarial verify" }

SKILL.md 3.5 KB

---
name: resilience-audit
description: >-
  Failure-mode audit (FMEA for software) — for each way the system can fail (network, storage, partial completion, crash, concurrency, bad input), check whether code DETECTS, HANDLES, RECOVERS, and COMMUNICATES it. Triggers on: "/resilience-audit", "resilience-audit", "FMEA audit". Use when touching network, storage, async, retry, or rollback paths. Flags data loss, silent-success-on-failure, missing rollback/retry/idempotency. Reports; does not fix unless asked.
---

# Resilience Audit

<!-- SHARED:LANGUAGE_HEADER -->

For every operation: **"what happens when this FAILS?"** Report; do NOT fix unless asked.

## Failure categories
1. **External I/O** — network down/slow, API 4xx/5xx/timeout, rate-limit. Retry w/ backoff? Timeout set? Clear error vs hang?
2. **Storage** — disk full, permission denied, partial write. Atomic write (temp+rename)? Cleanup on failure? Existing good copy untouched?
3. **Partial completion** — half-done op (50/100 files). Reported as FAILURE, never success.
4. **Crash / OOM** — killed mid-op. Idempotent restart? No orphaned half-state?
5. **Concurrency** — two instances, race, deadlock. Locking / idempotency / safe re-entry?
6. **Input / data** — malformed, null, truncated, huge. Validate at boundary? Fail-fast?
7. **Dependency down** — fallback/cache/graceful degrade? Clear error vs silent hang?
8. **Resource exhaustion** — bounded? Backpressure? Cleanup on error path?

Per-stack timeout/atomicity/idempotency patterns to grep: read `references/checks.md` before scanning.

## For each failure point, check 4 things
- **Detected?** code notices it (doesn't swallow)?
- **Handled?** retry/fallback/fail-clean — not ignored, not silent-success?
- **Recoverable?** rollback/idempotent; no data loss or corruption?
- **Communicated?** clear error to user+log; not a hang, not a false "done"?

## Discipline
- Trace actual failure path (cite file:line). Don't assume handling exists; prove it.
- "partial = failure" — any path reporting success on partial completion = CRITICAL.
- "logged" ≠ "handled" — swallowed+logged error that corrupts state or returns success = CRITICAL.

## Fix mode (choice-gated)
After the report, present via `ask_question`:
- **Fix safe ones** — add missing timeout, null/input validation, clear error+log on unhandled path. Each: checkpoint → fix → build+tests → revert if newly red.
- **Let me pick** — user-selected fixes only.
- **Report only** — change nothing.

NEVER auto-fix: retry/rollback/recovery/atomicity logic (semantic changes can introduce new failure modes).

## Grants & denials (CLASSIFY-BLOCK)
| class | step it powers | grant | on denial |
|---|---|---|---|
| read | trace failure paths for the 8 categories above | `Read`·`Grep`·`Glob` | refuse that file, name it — never a clean bill |
| write | Fix mode's safe-guard apply, incl. checkpoint → build+tests → revert if newly red | `Edit`·`Bash` (checkpoint/build/revert need exec) | report the fix as NOT applied AND the checkpoint/revert as NOT available, never claim done |

<!-- SHARED:CLASSIFY_BLOCK -->

## Output
`| operation | failure mode | effect | handling (file:line) | severity | recommended guard |`
Ordering/atomicity findings · Summary (counts + top fixes) · Not assessed

Severity: CRITICAL (data loss/corruption/silent-success) · HIGH (crash/hang/partial-no-recovery) · MEDIUM (poor degradation/missing retry) · LOW (cosmetic)

<!-- SHARED:REPORTING_FOOTER -->

<!-- SHARED:ORCHESTRATION -->

<!-- SHARED:ESCALATION_FOOTER -->