incident-response
Run an incident response workflow — triage, communicate, and write postmortem. Trigger with "we have an incident", "production is down", an alert that needs severity assessment, a status update mid-incident, or when writing a blameless postmortem after resolution.
Install
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill incident-responseSKILL.md
/incident-response
If you see unfamiliar placeholders or need to check which tools are connected, see CONNECTORS.md.
Manage an incident from detection through postmortem.
Usage
/incident-response $ARGUMENTS
Modes
/incident-response new [description] # Start a new incident
/incident-response update [status] # Post a status update
/incident-response postmortem # Generate postmortem from incident data
If no mode is specified, ask what phase the incident is in.
How It Works
┌─────────────────────────────────────────────────────────────────┐
│ INCIDENT RESPONSE │
├─────────────────────────────────────────────────────────────────┤
│ Phase 1: TRIAGE │
│ ✓ Assess severity (SEV1-4) │
│ ✓ Identify affected systems and users │
│ ✓ Assign roles (IC, comms, responders) │
│ │
│ Phase 2: COMMUNICATE │
│ ✓ Draft internal status update │
│ ✓ Draft customer communication (if needed) │
│ ✓ Set up war room and cadence │
│ │
│ Phase 3: MITIGATE │
│ ✓ Document mitigation steps taken │
│ ✓ Track timeline of events │
│ ✓ Confirm resolution │
│ │
│ Phase 4: POSTMORTEM │
│ ✓ Blameless postmortem document │
│ ✓ Timeline reconstruction │
│ ✓ Root cause analysis (5 whys) │
│ ✓ Action items with owners │
└─────────────────────────────────────────────────────────────────┘
Severity Classification
| Level | Criteria | Response Time |
|---|---|---|
| SEV1 | Service down, all users affected | Immediate, all-hands |
| SEV2 | Major feature degraded, many users affected | Within 15 min |
| SEV3 | Minor feature issue, some users affected | Within 1 hour |
| SEV4 | Cosmetic or low-impact issue | Next business day |
Communication Guidance
Provide clear, factual updates at regular cadence. Include: what's happening, who's affected, what we're doing, when the next update is.
Output — Status Update
## Incident Update: [Title]
**Severity:** SEV[1-4] | **Status:** Investigating | Identified | Monitoring | Resolved
**Impact:** [Who/what is affected]
**Last Updated:** [Timestamp]
### Current Status
[What we know now]
### Actions Taken
- [Action 1]
- [Action 2]
### Next Steps
- [What's happening next and ETA]
### Timeline
| Time | Event |
|------|-------|
| [HH:MM] | [Event] |
Output — Postmortem
## Postmortem: [Incident Title]
**Date:** [Date] | **Duration:** [X hours] | **Severity:** SEV[X]
**Authors:** [Names] | **Status:** Draft
### Summary
[2-3 sentence plain-language summary]
### Impact
- [Users affected]
- [Duration of impact]
- [Business impact if quantifiable]
### Timeline
| Time (UTC) | Event |
|------------|-------|
| [HH:MM] | [Event] |
### Root Cause
[Detailed explanation of what caused the incident]
### 5 Whys
1. Why did [symptom]? → [Because...]
2. Why did [cause 1]? → [Because...]
3. Why did [cause 2]? → [Because...]
4. Why did [cause 3]? → [Because...]
5. Why did [cause 4]? → [Root cause]
### What Went Well
- [Things that worked]
### What Went Poorly
- [Things that didn't work]
### Action Items
| Action | Owner | Priority | Due Date |
|--------|-------|----------|----------|
| [Action] | [Person] | P0/P1/P2 | [Date] |
### Lessons Learned
[Key takeaways for the team]
If Connectors Available
If ~~monitoring is connected:
- Pull alert details and metrics
- Show graphs of affected metrics
If ~~incident management is connected:
- Create or update incident in PagerDuty/Opsgenie
- Page on-call responders
If ~~chat is connected:
- Post status updates to incident channel
- Create war room channel
Tips
- Start writing immediately — Don't wait for complete information. Update as you learn more.
- Keep updates factual — What we know, what we've done, what's next. No speculation.
- Postmortems are blameless — Focus on systems and processes, not individuals.
Related skills
azure-diagnosticsmicrosoft608KDebug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deployment failure, troubleshoot container apps, troubleshoot functions, troubleshoot AKS, VM RDP, Linux SSH, VM black screen, can't connect to VM, reset VM password, NSG or firewall blocking, kubectl cannot connect, kube-system/CoreDNS failures, pod pending, crashloop, node not ready, upgrade failures, aazure-preparemicrosoft608KPrepare azd-based Azure projects for deployment: generates azure.yaml, infrastructure (Bicep/Terraform), and Dockerfiles for the Azure Developer CLI (azd) workflow. USE ONLY when the user explicitly wants to use azd as the deployment tool, or the project already has an azure.yaml file. DO NOT USE FOR: non-azd deployments, Python App Service code-only deploys (use python-appservice-deploy), or cross-cloud migration (use azure-cloud-migrate). WHEN: prepare app for azd, create azure.yaml, set up azazure-aimicrosoft608KUse for Azure AI: Search, Speech, OpenAI, Document Intelligence. Helps with search, vector/hybrid search, speech-to-text, text-to-speech, transcription, OCR. WHEN: AI Search, query search, vector search, hybrid search, semantic search, speech-to-text, text-to-speech, transcribe, OCR, convert text to speech.azure-deploymicrosoft607KExecute Azure deployments for ALREADY-PREPARED applications that have existing .azure/deployment-plan.md and infrastructure files. DO NOT use this skill when the user asks to CREATE a new application — use azure-prepare instead. This skill runs azd up, azd deploy, terraform apply, and az deployment commands with built-in error recovery. Requires .azure/deployment-plan.md from azure-prepare and validated status from azure-validate. WHEN: \"run azd up\", \"run azd deploy\", \"execute deployment\",