| name | postmortem-authoring |
| description | Authors blameless incident and defect postmortems with timeline, impact, root cause, and corrective actions. Use after incidents or for formal defect write-ups. |
Postmortem authoring
Purpose
Produce a blameless, evidence-based postmortem suitable for stakeholders and future search—grounded in logs, deploys, and metrics, not speculation.
When to Use
- User asks for incident postmortem, RCA document, or defect write-up.
- After mitigation when timeline and impact need formal capture.
- Publishing to docs/tickets via google-docs, github, or jira.
When NOT to Use
- Active incident command → lead-incidents, coordinate-incidents first.
- Threat design review → threat-modeling.
- Skill repo authoring → create-skill / publish-skill.
Expected Outcome
- Complete postmortem draft with required sections and explicit unknowns.
- Corrective actions with owners and dates when provided.
- UTC timeline aligned to evidence sources.
Inputs to Gather
- Incident window (UTC), severity, and services affected.
- Alerts, deploys, feature flags, and key log/metric links.
- Customer/revenue/SLO impact estimates.
- Existing tickets or chat threads.
Workflow
- Collect evidence (alerts, deploys, dashboards) before drafting narrative.
- Build UTC timeline with source citations.
- Draft sections below; mark gaps as unknown.
- Separate proximate vs contributing causes without blaming individuals.
- Propose corrective actions (quick wins + systemic); request owners/dates.
- Review for blameless language and sensitive data redaction.
Domain guidance
Produce a blameless document suitable for stakeholders and future search.
Sections
- Summary — what broke, for whom, how long.
- Timeline — evidence-based (logs, deploys, alerts), UTC.
- Impact — users, revenue, SLOs, data.
- Root cause — mechanism, not individuals; proximate vs contributing.
- Detection — why it was not caught earlier.
- Mitigation — what stopped the bleeding.
- Corrective actions — owned, dated; quick wins and systemic fixes.
Stay factual; mark unknowns explicitly.
Tool Availability Rules
| Access | Behavior |
|---|
| Full tool access | Pull evidence from connected tools; publish doc if asked. |
| Read-only | Draft from user-provided evidence only. |
| No integration | Draft structure; user supplies links and timestamps. |
Related tool sets
Review / Decision / Execution Criteria
- Every timeline entry traceable to a source.
- Corrective actions are SMART where possible.
- No naming individuals as root cause.
Output Format
Markdown or doc-ready sections per template above, plus optional one-paragraph executive summary.
Quality Bar
- Suitable for exec + engineering audiences.
- Distinguishes facts, hypotheses, and unknowns.
Safety and Boundaries
- Redact customer PII and secrets from excerpts.
- Do not fabricate deploy times or metric values.
Escalation / Dispatch Rules
- SLO policy implications → error-budget-management.
- Ongoing reliability work → monitor-slos.
References
skills/old_skills.json (postmortem-authoring).skills/skill.instruction.md, skills/meta.instructions.md
