agentleFS
m2ai-mcp-serversm2ai-mcp-servers/claude-skills/skills/failure-postmortem/SKILL.md

failure-postmortem

Skill0 starsChanged 7 months agoMITView on GitHub

Guide a structured AI system failure post-mortem using 6 named failure patterns, producing a publishable incident report.

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use when the user says "post-mortem", "failure analysis", "what went wrong with the agent", "debug this failure", or describes an AI system …

    line 12
  2. Distinctive:

    Ask the user for:

    line 16
  3. Distinctive:

    Keep questions tight. One round of clarification max.

    line 22
  4. Distinctive:

    Ask if any corrective actions should be implemented now

    line 89

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Failure Post-Mortem Builder

Build a structured post-mortem for an AI system failure. Walks through diagnosis using 6 named failure patterns and produces a publishable incident report.

Trigger

Use when the user says "post-mortem", "failure analysis", "what went wrong with the agent", "debug this failure", or describes an AI system that produced bad output.

Phase 1: Incident Capture

Ask the user for:

  1. What happened -- the observed bad behavior or output
  2. What was expected -- the correct behavior
  3. System context -- which agent/model/pipeline, what inputs triggered it
  4. Impact -- who was affected, what was the blast radius

Keep questions tight. One round of clarification max.

Phase 2: Failure Pattern Classification

Classify the failure against these 6 patterns (multiple can apply):

PatternDescriptionDiagnostic Signal
Context DegradationAgent lost track of critical context mid-task due to window limits, compaction, or prompt structureOutput quality dropped partway through; early steps were fine
Specification DriftThe spec/prompt was ambiguous or incomplete; agent filled gaps with assumptionsAgent did something "reasonable" but wrong; spec didn't define the edge case
Sycophantic ConfirmationAgent agreed with flawed premises or user errors instead of pushing backUser provided wrong info; agent incorporated it without challenge
Tool Selection ErrorAgent chose the wrong tool, wrong API, or wrong approach for the taskRight intent, wrong execution method; tool existed but wasn't selected
Cascade FailureOne error propagated through multiple steps, each compounding the damageSmall initial mistake; large final deviation; intermediate steps didn't catch it
Silent FailureAgent completed without errors but output was wrong; no signal that anything failed"Success" with bad results; no errors, no warnings, no escalation

For each matching pattern, explain:

  • Why this pattern fits
  • Which specific moment in the execution triggered it
  • What guardrail was missing

Phase 3: Root Cause

Identify the deepest cause. Use the "5 Whys" technique:

  1. Why did the failure occur? -> [pattern-level answer]
  2. Why was that possible? -> [missing guardrail / spec gap]
  3. Why was that guardrail missing? -> [process / design gap]
  4. Continue until you hit a systemic cause
  5. State the root cause in one sentence

Phase 4: Post-Mortem Report

Generate a structured report:

# AI Failure Post-Mortem: [Short Title]

**Date**: [date]
**System**: [agent/pipeline name]
**Severity**: [LOW / MEDIUM / HIGH / CRITICAL]
**Status**: [investigating / mitigated / resolved]

## Incident Summary
[2-3 sentences: what happened, what was expected, what was the impact]

## Timeline
- [timestamp/step] -- [what happened]
- ...

## Failure Patterns Identified
### [Pattern Name]
[explanation, evidence, missing guardrail]

## Root Cause
[one-sentence root cause from 5 Whys]

## Corrective Actions
| Action | Type | Priority | Owner |
|--------|------|----------|-------|
| [specific fix] | [prevent / detect / mitigate] | [P0-P3] | [who] |

## Lessons Learned
- [insight that applies beyond this specific incident]

Phase 5: Verification

  • Confirm the report captures the user's understanding of what happened
  • Ask if any corrective actions should be implemented now
  • Offer to save the report to the vault or a project directory

Source

Extracted from Nate Kadlac newsletter (2026-03-26) -- "The K-Shaped AI Labor Market" -- failure pattern taxonomy for AI system quality judgment.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.