Postmortem

Skill nubasu/Pseudo-Fable-Framework/frameworks/pseudo-fable-incident/.claude/skills/postmortem

Written by Fable, for models that aren't — context frameworks that lift Opus/Sonnet-class agents to Fable-grade work discipline.

Install

npx -y skills add nubasu/Pseudo-Fable-Framework --skill postmortem

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Blameless postmortem after a resolved incident — reconstruct the timeline, compute time-to-detect / time-to-mitigate / time-to-resolve, separate root cause from contributing factors, mine what-went-well and what-was-lucky, produce action items through three lenses (detect faster / prevent the class / mitigate faster), and route lessons into rules via retro. Use after incident-response closes; the incident is not done until this exists.

SKILL.md

3.0 KB, as published. Nobody here has run it

postmortem — the incident pays for itself here

Blameless means: systems and processes fail, not people — and not models. The question is always "why did the system allow this?", never "who screwed up?". An agent error is a missing check; find the check.

1. Reconstruct

From the incident file's timeline:

Key timestamps: symptom start → detection → mitigation → diagnosis → resolution.
The three durations that matter, each a separate improvement target: time-to-detect (start → detection) · time-to-mitigate (detection → mitigation) · time-to-resolve (detection → resolution).

2. Causes — root and contributing

Root cause as a mechanism, concrete enough that the fix follows from it ("connection pool exhausted because retries lacked backoff" — not "high load").
Contributing factors — there are usually ≥2 beyond the trigger: the latent weakness that made it possible, and the detection gap that let it grow. Ask "why" until the answers stop being actionable, then stop.
What went well, and what was merely lucky. Luck is a risk that didn't fire this time — price it as a finding.

3. Action items — three lenses, every item concrete

Lens	Question
Detect faster	What alert / log / metric would have caught this in minutes? (No observability at all? That IS the action item.)
Prevent the class	What kills the CLASS, not the instance? (validation, type, test, config guard — and grep for siblings now)
Mitigate faster	What would have stopped the bleeding sooner? (rollback tooling, feature flags, a runbook line)

Each item: concrete action + destination (ticket / immediate fix / runbook) + priority. Action items are work items — there may be many; that is fine.

4. Route the lessons

Context rules go through retro's placement table and its ≤2-rules constraint: repo trap → Gotchas · process failure → project CLAUDE.md · generic → propose to the store.
Operational mechanics ("how to roll back service X") → the project's runbook/docs, not CLAUDE.md.

5. Write it

docs/postmortems/<date>-<slug>.md — durable and human-visible (not .claude/state/):

# <title>                      (date · severity · duration)
## Impact         — who / what / how long, in numbers
## Timeline       — timestamped, from the incident file
## Root cause     — the mechanism
## Contributing   — latent weakness · detection gap
## Went well / was lucky
## Action items   — lens / action / destination / priority

Keep it under a page. A postmortem nobody reads prevents nothing.

Gives 1 of the 12 instructions most incident response skills give

Counted across 224 of the 224 authors here whose files we hold, read 2026-08-06

Conduct a blameless postmortem within 48 hoursin 24 of 224, across 14 files
perform root cause analysis using five whysin 24 of 224, across 20 files
write a blameless postmortemin 22 of 224, across 19 files
Update stakeholders every 15 to 30 minutesin 19 of 224, across 9 files
assign an owner and due date to every action itemin 18 of 224
Classify incident severity within 5 minutesin 17 of 224, across 7 files
Create a post-mortem documenthere, and in 17 of 224, across 14 files
Assign all action items with deadlinesin 14 of 224, across 6 files
Implement immediate mitigation prioritizing user restorationin 13 of 224, across 3 files
assign one incident commanderin 12 of 224
Stop and ask for clarification if inputs are missingin 10 of 224, across 2 files
Escalate earlyin 10 of 224, across 2 files

Said here and by no other author read

find the missing check
compute time-to-detect, time-to-mitigate, and time-to-resolve
price what was lucky as a finding
assign a destination and priority to each action item
route context rules through retro
route operational mechanics to the runbook

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.