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
1---2name: postmortem-authoring3description: Authors blameless incident and defect postmortems with timeline, impact, root cause, and corrective actions. Use after incidents or for formal defect write-ups.4---56# Postmortem authoring78## Purpose910Produce a blameless, evidence-based postmortem suitable for stakeholders and future search—grounded in logs, deploys, and metrics, not speculation.1112## When to Use1314- User asks for incident postmortem, RCA document, or defect write-up.15- After mitigation when timeline and impact need formal capture.16- Publishing to docs/tickets via **google-docs**, **github**, or **jira**.1718## When NOT to Use1920- Active incident command → **lead-incidents**, **coordinate-incidents** first.21- Threat design review → **threat-modeling**.22- Skill repo authoring → **create-skill** / **publish-skill**.2324## Expected Outcome2526- Complete postmortem draft with required sections and explicit unknowns.27- Corrective actions with owners and dates when provided.28- UTC timeline aligned to evidence sources.2930## Inputs to Gather3132- Incident window (UTC), severity, and services affected.33- Alerts, deploys, feature flags, and key log/metric links.34- Customer/revenue/SLO impact estimates.35- Existing tickets or chat threads.3637## Workflow38391. Collect evidence (alerts, deploys, dashboards) before drafting narrative.402. Build UTC timeline with source citations.413. Draft sections below; mark gaps as unknown.424. Separate proximate vs contributing causes without blaming individuals.435. Propose corrective actions (quick wins + systemic); request owners/dates.446. Review for blameless language and sensitive data redaction.4546## Domain guidance4748Produce a **blameless** document suitable for stakeholders and future search.4950### Sections51521. **Summary** — what broke, for whom, how long.532. **Timeline** — evidence-based (logs, deploys, alerts), UTC.543. **Impact** — users, revenue, SLOs, data.554. **Root cause** — mechanism, not individuals; proximate vs contributing.565. **Detection** — why it was not caught earlier.576. **Mitigation** — what stopped the bleeding.587. **Corrective actions** — owned, dated; quick wins and systemic fixes.5960Stay factual; mark unknowns explicitly.6162## Tool Availability Rules6364| Access | Behavior |65|--------|----------|66| Full tool access | Pull evidence from connected tools; publish doc if asked. |67| Read-only | Draft from user-provided evidence only. |68| No integration | Draft structure; user supplies links and timestamps. |6970### Related tool sets7172- `jira`73- `github`74- `google-docs`7576## Review / Decision / Execution Criteria7778- Every timeline entry traceable to a source.79- Corrective actions are SMART where possible.80- No naming individuals as root cause.8182## Output Format8384Markdown or doc-ready sections per template above, plus optional one-paragraph executive summary.8586## Quality Bar8788- Suitable for exec + engineering audiences.89- Distinguishes facts, hypotheses, and unknowns.9091## Safety and Boundaries9293- Redact customer PII and secrets from excerpts.94- Do not fabricate deploy times or metric values.9596## Escalation / Dispatch Rules9798- SLO policy implications → **error-budget-management**.99- Ongoing reliability work → **monitor-slos**.100101## References102103- `skills/old_skills.json` (`postmortem-authoring`).104- `skills/skill.instruction.md`, `skills/meta.instructions.md`
poly-gents