Blameless Post Mortem

blameless-post-mortem

Facilitate a blame-free post-mortem after an incident or near-miss. Consumes the incident-commander skeleton, derives or fills the root cause, writes the corrective-action plan, and drafts an incident-learnings memory candidate. Systems and processes are examined — never individuals.

When to use

• An incident or outage is resolved and the team needs a structured write-up.
• A near-miss happened and a post-mortem is being drafted (near-miss mode — same flow, different severity framing).
• The incident-commander hands off a post-mortem skeleton (empty root cause is accepted — do not block on it).
• German triggers: "Post-mortem", "Nachbesprechung", "was ist schiefgelaufen?", "Vorfallsanalyse".

Do NOT use when:

• The incident is still active — route to incident-commander first.
• The goal is root-cause analysis only, no write-up needed — route to root-cause-frameworks.
• The concern is a future risk, not a past event — route to risk-officer.

Procedure

1. Consume the incident-commander skeleton

Read the incoming skeleton. Per docs/contracts/analysis-memory-loop.md § 5:

• Accept any skeleton, complete or not.
• Extract: SEV, State, Started, Timeline, Mitigation, Root cause (may be unknown or TBD).
• Do NOT stall or reject on an empty root cause.

If no skeleton is provided, reconstruct from the user's description: severity, timeline, impact, mitigation state.

2. Derive the root cause (if unresolved)

If root cause is unknown or TBD, invoke root-cause-frameworks. That skill returns ranked candidates with confidence levels — do NOT force a verdict. If root cause remains unresolved after the analysis pass, mark the post-mortem status: draft and continue. A draft post-mortem can still produce memory candidates (note the open question in the candidate summary).

3. Write the blame-free report

Sections in order — no individuals named, systems and processes only:

1. Summary — one paragraph, blame-free, what happened and the business impact.
2. Timeline — reference the skeleton timeline; do NOT rebuild it.
3. Impact — users affected, duration, data, revenue, SLA.
4. Detection — how the incident was discovered (monitoring, user report, alert, manual).
5. Root cause — the confirmed or highest-confidence candidate; state confidence level if draft.
6. Contributing factors — conditions that made the root cause possible (tooling gaps, process gaps, system state).
7. What went well — at least one item; omitting this is a smell.
8. What went wrong — process, tooling, signals, communication gaps. No individual blame.

Near-miss mode: same sections; set SEV: near-miss. Add two extra questions after "what went wrong":

• "What would have made this worse?"
• "Which control caught it — luck or a designed control?"

4. Corrective actions (folded-in phase)

For each identified gap, propose a corrective action. Reuse risk-officer mitigation framing: owner role, size, residual-risk note. Four action types:

Each action MUST have:

• Owner role (eng, ops, PO, support — never "the team")
• Closure criterion — specific, testable condition marking the action done
• Regression signal — a test, monitor, or alert that proves the fix held

An action without a closure criterion is a wish, not a plan.

5. Memory write-back

Per docs/contracts/analysis-memory-loop.md § 2:

1. Run the dedup pre-check — find_duplicate(...) from scripts/memory_lookup.ts over the same key-space (incident type, affected paths, decision area); a memory:lookup query over the same keys is the CLI equivalent.

2. Match found — propose a frequency / supersedes update to the existing entry; do NOT create a new candidate.

3. No match — draft a REDACTED incident-learnings candidate to /memory propose:

   • type: incident-learnings
   • summary: one-line pattern (no customer names, no secrets, no project-rooted paths)
   • evidence_paths: ≥ 2 file paths (for admission gate)
   • decision_surface: ≥ 3 decisions this pattern changes (if possible)
   • last_validated: today
   • review_after_days: 90
   • applicable_scope: project

4. NEVER auto-promote. The human drives promotion via /memory promote. If the candidate fails the admission gate (check_memory_proposal.ts), surface the gap to the user.

If the lookup surfaces stale entries (past review_after_days), surface them explicitly — never silently use stale data.

Output

The post-mortem produces, in order:

1. Post-mortem document — sections 1–8 from step 3; status final or draft if root cause is unresolved.
2. Corrective-action table — each action with type, owner, closure criterion, regression signal.
3. Memory candidate — the drafted incident-learnings JSONL snippet for /memory propose (or the frequency-update proposal if a duplicate was found).

Do NOT

• Do NOT blame individuals — name systems, processes, signals, tooling.
• Do NOT auto-promote to curated memory — the gate is human-driven.
• Do NOT skip the dedup pre-check before drafting a memory candidate.
• Do NOT ship raw PII, customer names, secrets, or project-rooted paths in the memory candidate (redact per the contract).
• Do NOT reject or stall on an incomplete skeleton — mark draft and continue.
• Do NOT rebuild the timeline from scratch — reference the skeleton's timeline.

Gotchas

• Incomplete skeleton → status: draft, not a rejection. Draft post-mortems still produce memory candidates with the open question noted.
• Near-miss → a mode within this skill, not a separate flow. Severity is near-miss; the extra two questions apply.
• Corrective actions without closure criteria are non-actionable. Always require a specific, testable done condition.
• Stale memory entries must be surfaced as stale, never merged into the findings. Never silently reuse stale data.

See also

• incident-commander — produces the skeleton this skill consumes; run first during live incidents.
• root-cause-frameworks — RCA engine invoked in step 2 when root cause is unresolved.
• risk-officer — mitigation framing reused for corrective actions (owner, size, residual-risk).
• docs/contracts/analysis-memory-loop.md — produce → propose → promote → retrieve contract this skill binds to.