| name | incident |
| description | Generate an incident summary, timeline, and stakeholder communication from ongoing incident notes |
Help me manage and document an ongoing or recently resolved incident.
Ask me:
- "What is the service affected and what is the symptom?" (if not already in context)
- "Do you want: (a) a live incident status update, (b) a post-mortem draft, or (c) both?"
For option (a): Live incident status update
Generate a stakeholder communication (Slack message format) from the details I provide:
:red_circle: *INCIDENT - [SERVICE] - [SHORT DESCRIPTION]*
*Status:* Investigating / Mitigating / Resolved
*Severity:* P0 / P1 / P2
*Impact:* [What is broken, who is affected, since when]
*Current actions:* [What the team is doing right now]
*Next update:* [Time of next status update]
Incident channel: #inc-[service]-[date]
Incident commander: [name]
Then generate a separate engineering-focused channel update:
*Technical status:*
- Symptoms: [error rates, latency, logs observed]
- Hypothesis: [current working theory]
- Actions taken: [list with timestamps]
- Next step: [what you're trying next]
For option (b): Post-mortem draft
Generate a post-mortem document from the information I provide:
Post-mortem: [Incident Title]
Date: [date]
Duration: [start time] → [end time] ([X hours Y minutes])
Severity: P0 / P1
Author: [name]
Reviewers: [names]
Summary
[2-3 sentences: what happened, what was the impact, how it was resolved]
Impact
- User impact: [What users experienced]
- Duration: [Total downtime or degradation window]
- Error rate: [Peak error rate / normal baseline]
- Affected services: [List]
Timeline
| Time (UTC) | Event |
|---|
| HH:MM | Alert fired |
| HH:MM | On-call acknowledged |
| HH:MM | [Key investigation step] |
| HH:MM | Root cause identified |
| HH:MM | Mitigation applied |
| HH:MM | Service restored |
| HH:MM | Incident resolved |
Root cause
[Clear, technical explanation of what went wrong. Avoid blame — focus on system conditions.]
Contributing factors
- [Factor 1: e.g., "Missing circuit breaker allowed cascading failures"]
- [Factor 2: e.g., "Alert threshold too high — fired 12 minutes after users were affected"]
What went well
- [Thing 1: e.g., "Runbook was up to date and accurate"]
- [Thing 2: e.g., "Team communicated clearly in incident channel"]
What could be improved
- [Thing 1: e.g., "No automated rollback — required manual intervention"]
- [Thing 2: e.g., "Log retention too short to reconstruct full timeline"]
Action items
| Action | Owner | Due date | Priority |
|---|
| Add circuit breaker to downstream calls | [team] | [date] | HIGH |
| Lower alert threshold to detect earlier | [team] | [date] | MEDIUM |
| Add deployment smoke test | [team] | [date] | MEDIUM |
Draft generated by Kiro /incident skill — review and edit before publishing