Generate a blameless post-mortem from template. Use when the user says "write a post-mortem", "incident report", "what went wrong", "document the outage", or after a production incident.
Instalación
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Generate a blameless post-mortem from template. Use when the user says "write a post-mortem", "incident report", "what went wrong", "document the outage", or after a production incident.
disable-model-invocation
false
user-invocable
true
argument-hint
[incident title or date]
Generate Post-Mortem
Path Resolution
Read workflow.json in the project root
If it exists and docsRepo is ".": this IS the docs repo — use local paths
If it exists and docsRepo is a repo name: resolve via pwsh .claude/skills/tool-worktree/scripts/resolve-repo.ps1 <docsRepo> to get the docs root path. Templates at <resolved>/templates/, output to <resolved>/postmortems/
If no workflow.json: templates at templates/, output to docs/postmortems/
Instructions
Resolve paths (see Path Resolution above)
Read the template at <templates>/postmortem.md
Gather incident details:
What happened? When?
What was the impact? (users, revenue, SLA)
What was the timeline? (detection → response → resolution)
What was the root cause?
Generate the post-mortem following blameless principles:
Focus on systems, not people — "the deploy pipeline didn't catch X" not "Bob forgot to check X"
Be specific about impact — numbers, not adjectives
Timeline must be precise — include timestamps
Action items must be actionable — assigned owner, due date, clear definition of done
Save to <output>/[date]-[slug].md
Blameless Principles
Use passive voice or system-focused language for failures
"What went well" section is mandatory — acknowledge good response
"Where we got lucky" exposes hidden risks
Action items should prevent recurrence, improve detection, AND improve response
Quality Checklist
Summary is 2-3 sentences (scannable)
Impact has concrete numbers
Timeline has timestamps (not "then... later...")
Root cause is technical and specific
Contributing factors are listed (root cause is never the only factor)
Detection section identifies the gap
Action items have owners and due dates
At least one action each for: prevent, detect, respond
"Where we got lucky" section is filled in
Tone is blameless throughout
Tips
Write the timeline first — it structures everything else
The "where we got lucky" section is often the most valuable
Every post-mortem should update at least one runbook
Link to monitoring dashboards and log queries for evidence
