Failure mode audit

failure-mode-audit — The Seven Failure Modes, as a checklist you run

Purpose

Autonomous agents fail in a small number of recognizable ways. This skill takes a plan, a transcript, or a proposed task and checks it against all seven, names the ones present, and gives each a concrete fix. Run it before a long autonomous run (on the plan) and after one that went wrong (on the transcript).

How to run

1. Get the target. Ask which you're auditing if unclear:
   • a plan / task description (pre-flight audit), or
   • a transcript / session the user pastes or points to (post-mortem audit).
2. Score each of the seven below. For each, decide: PRESENT, AT RISK, or CLEAR, and cite the specific line/step that triggered the call. Never mark PRESENT without quoting the evidence.
3. Output the report (format at the bottom). Lead with the modes that are PRESENT.
4. If auditing a plan, rewrite the riskiest 1–3 steps inline to remove the failure mode.

The seven failure modes

1. One-shot impulse

The agent tries to do everything in a single pass — reads everything, edits everything, exhausts its context, and leaves a trail of half-applied fragments.

• Tells: no decomposition; a single giant step; "I'll now implement the whole feature."
• Fix: force a decomposition step first. The plan must list discrete, independently verifiable units, each small enough to finish and check before the next begins.

2. Premature "done"

Declares victory with most of the work unfinished — tests unwritten, edge cases ignored, the actual integration never wired.

• Tells: "Done!" with no verification step; success claimed before any test/run; a checklist where items are marked complete without evidence.
• Fix: define "done" as an observable condition up front (a passing command, a rendered screen), and require the agent to produce that evidence before claiming completion.

3. Context anxiety

Near the context limit, the agent rushes — truncating work it had capacity to finish, wrapping up early "to be safe."

• Tells: quality drops in the back half; abrupt summarization; "to conserve context I'll…" when plenty remains.
• Fix: offload state to disk/memory at checkpoints so the window isn't the working set; give the agent an explicit handoff mechanism (see the context-handoff skill) so nearing the limit triggers a clean save, not a panic.

4. Self-evaluation inflation

The thing that produced the work also grades it — and grades its own broken output highly.

• Tells: the agent reviews its own code and says "looks great, 9/10"; no independent check.
• Fix: separate generation from certification. A different agent/pass — or an external tool (tests, type-checker, a run) — must be the grader. The generator never certifies itself.

5. Skipping end-to-end

Unit tests pass; the actual button does nothing. The agent validated the parts, never the whole.

• Tells: only unit-level checks; no run of the real flow; "tests pass" with no E2E.
• Fix: require at least one real end-to-end exercise of the user-visible path before done.

6. Stub-ification

The UI looks complete; the interactions are hollow. Handlers return mock data, buttons are wired to TODO, the happy path is a façade.

• Tells: mock/placeholder returns left in; "I'll stub this for now" never revisited; components that render but don't act.
• Fix: track every stub as an explicit open item; "done" requires zero unresolved stubs on the in-scope path. Mock data must be labeled and surfaced, never silently shipped.

7. Spec cascade

A planner's one wrong detail poisons everything downstream — every later step faithfully builds on the bad assumption.

• Tells: a single upstream artifact (a plan, a schema, a name) that all later work depends on, with no validation gate after it.
• Fix: validate the high-leverage upstream artifact against reality before fanning out. Put a checkpoint right after the plan/spec and before any dependent execution.

Report format

## Failure-Mode Audit — <plan name / session>

PRESENT (fix before proceeding)
  ⛔ #<n> <name> — <quoted evidence>
     Fix: <specific, actionable>

AT RISK (watch / harden)
  ⚠️ #<n> <name> — <why>
     Hardening: <specific>

CLEAR
  ✅ #<n> <name>

Verdict: <SHIP / FIX-FIRST / REPLAN> — <one line>

Notes

• Be specific and evidence-based. A mode is only PRESENT if you can quote the trigger.
• When in doubt between AT RISK and CLEAR, choose AT RISK — the cost of a missed failure mode in a long autonomous run is high; the cost of a little extra hardening is low.