Failure Mode Awareness

Failure Mode Awareness

Purpose

Cheap foresight beats expensive hindsight. Most failures aren't exotic — they're standard, catalogued, and visible in advance to anyone who asks "how does this break?" before asking "how does this work?" This skill runs that question early, when changing course costs a sentence instead of a rewrite.

When to use this skill

• At plan time (plan-gate risk section) and design time — before the approach hardens.
• Before recommending a course of action the user will invest in.
• When reviewing someone else's plan, proposal, or idea.
• Before shipping anything with real blast radius: data migrations, external sends, public artifacts.

When NOT to use this skill

• On finished work — that's adversarial-verify's job (attack the artifact, not the idea).
• On low-stakes, reversible tasks. Enumerating failure modes for a typo fix is noise.
• As a reason not to act: the output is mitigations and watch-items, not paralysis.

Operating procedure

Step 1 — Run the premortem. "It's three months later and this failed. What's the most boring, most likely reason?" Write down the top 2–3. The boring qualifier matters: real failures are usually mundane (nobody used it, the data was dirty, the dependency changed), not dramatic.

Step 2 — Sweep the relevant catalog (pick the sections that apply):

Software failures

• Edge inputs: empty, null, zero, negative, huge, duplicate, malformed, unicode.
• State: concurrent access, partial failure mid-operation, retries causing double-execution, stale caches.
• Integration: the other system is down, slow, rate-limiting, or returns a shape you didn't expect.
• Environment: works locally, differs in prod (versions, permissions, paths, env vars, clock, locale).
• Scale and time: fine at 10 rows, dead at 10 million; fine today, broken at month-end/DST/leap year.

Reasoning failures

• Anchoring on the first hypothesis; confirmation bias in which evidence gets collected.
• Survivorship bias (studying only what succeeded); base-rate neglect ("this time is different").
• Extrapolating from an unrepresentative sample; correlation read as cause.

Communication failures

• The lede is buried; the reader acts on the first paragraph and misses the correction in the fourth.
• Wrong audience register: jargon for executives, hand-waving for engineers.
• Ambiguity someone will resolve the wrong way ("next Friday", "the new version", unowned action items).

Business/strategy failures

• Demand assumed, not validated; distribution unplanned ("build it and they will come").
• Unit economics that don't survive scale; single points of dependency (one customer, one channel, one platform's policy).
• Competitor/platform response ignored; timeline assumes nothing slips.

Workflow failures

• Handoffs where context evaporates; work that silently drifts from the request (see scope-fence).
• No definition of done, so it's never done; blocked items with no owner, waiting forever.
• Verification skipped under deadline pressure — precisely when errors are most likely.

Step 3 — Rate and respond. For each identified mode: likelihood (L/M/H) × impact (L/M/H). Then choose:

• Mitigate now (high L or H impact, cheap to address) — change the design, add the check.
• Watch — name the early-warning signal that says it's happening.
• Accept — explicitly, with a note. Accepted risks are fine; unexamined ones are not.

Step 4 — Fold results into the plan. Failure modes that survive go into plan-gate's Risks section or the deliverable's caveats — not into a separate document nobody reads.

Quality bar

• The top failure mode identified is plausible and specific to this task, not generic ("something might break").
• Every High-impact mode has a mitigation, a watch signal, or an explicit acceptance.
• The whole pass fits the stakes: three lines for a Medium task, a structured table only when Critical.

Common failure modes (of this skill itself)

• Catastrophizing: listing twenty theoretical risks, drowning the two real ones. Rank ruthlessly; report the top few.
• Generic risk lists: "scope creep, technical debt, timeline risk" pasted onto any project. If the risk list would fit a different project unchanged, it's decoration.
• Premortem as ritual: writing risks, then designing exactly as if they didn't exist. Step 4 is the point.
• Only-software blindness: checking edge cases in code while the actual failure is that the output will be misread (communication) or unneeded (strategy).

Example

Plan: "Nightly script exports user data to the analytics vendor." Premortem top hits: (1) Script silently stops running and nobody notices for weeks — boring, likely. Mitigate: success heartbeat + alert on absence. (2) Schema change upstream breaks the export mid-quarter — watch: row-count drop alert. (3) PII lands in the export that shouldn't — high impact: mitigate now with an explicit allowlist of fields rather than select *. Accepted: vendor outage delays data by a day (low impact, retry handles it).

Works with sibling skills

• Feeds the Risks section of plan-gate; runs during design, before execution.
• adversarial-verify is the post-hoc twin: this skill predicts failure in plans, that one hunts it in finished work.
• proactive-rigor surfaces the missing information class of risk; this skill covers the known-mechanism class.
• debugging-playbook uses the software catalog in reverse — as a source of hypotheses for existing failures.

Provenance and maintenance

Written 2026-07 as part of a portable, project-agnostic quality pack. Catalog entries are standard, well-documented failure classes, not project claims. Re-verify by post-incident review: when something fails that this skill should have caught, add the mode to the catalog section it belongs to. Prune any entry that has never once fired for your work.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: ralfyishere
• Source: ralfyishere/rules-with-receipts
• License: MIT

Install and usage instructions live in the source repository linked above.