failure-mode-awareness

name

Failure Mode Awareness

description

Identify what could go wrong before it goes wrong. Activate when designing anything new, before committing to a plan or recommendation, before shipping changes with real blast radius, and when evaluating ideas, strategies, or proposals. Trigger signals: "will this work?", "review this plan", "any risks?", designing an integration or workflow, writing a strategy or proposal, or a plan that contains zero mention of what could fail. Complements adversarial-verify, which attacks finished work; this skill runs earlier, on designs and plans.

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.