← ClaudeAtlas

failure-mode-enumerationlisted

Systematically enumerate how code can break — boundaries, concurrency, partial failure, malicious input, time, resource exhaustion — before writing defenses, then convert the list into tests and guards while pruning paranoia that does not pay rent.
rlaope/ultraprompt · ★ 32 · AI & Automation · score 72
Install: claude install-skill rlaope/ultraprompt
# Failure-Mode Enumeration > Status: v0.1 baseline draft — derived from the case catalog and axis definitions; awaiting trace evidence from Fable 5.1 case runs. ## When to apply - Writing any code that crosses a trust or process boundary: network calls, disk I/O, user input, IPC, subprocess spawning. - Designing a system where partial failure is possible: queues, retries, distributed transactions, multi-step writes. - Implementing a parser, protocol handler, or format decoder that will receive arbitrary bytes. - Adding concurrency: shared state, locks, async cancellation, anything with more than one thread of execution. - Reviewing code before shipping when the cost of a production failure is high (payments, data loss, security). - The user asks "what could go wrong here?" or wants tests hardened against edge cases. ## Core loop 1. **Fix the unit of analysis first.** Name the exact function, endpoint, or state machine you are enumerating against. Enumerating "the system" produces vague worry; enumerating `consume_message()` produces a checklist. Write the unit's contract in one line: inputs, outputs, and the invariants that must hold after it runs. 2. **Run the standard failure taxonomy against it, category by category.** Do not brainstorm freely — walk the fixed list so nothing is skipped: - **Boundary values**: zero, one, max, max+1, negative, empty string/list/map, exactly-at-limit. - **Huge inputs**: 10^6x the expected size — does memory, latency, or a do