# Failure Mode Audit

> Audit a plan, an agent session, or a proposed autonomous run against the seven known failure modes of autonomous agents, and prescribe the verified fix for each one present. Use when the user says "audit this plan", "failure mode check", "why did my agent stall", "review this agent run", or before launching a long autonomous task.

- Skill: `aimasteracc/failure-mode-audit` (Agent Skill)
- Install (CLI): `npx skillmds@latest add aimasteracc/failure-mode-audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aimasteracc/failure-mode-audit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: aimasteracc (https://skillmd.com/u/aimasteracc)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/aimasteracc/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.