Skill

Official

Pass

Audit score 90

incident-response

anthropics/knowledge-work-plugins

Manage incidents from detection through postmortem with triage, communication, and blameless analysis.

What is incident-response?

Structured incident response workflow that guides you through triage (severity assessment, role assignment), communication (status updates, customer messaging), mitigation (timeline tracking, resolution confirmation), and postmortem (root cause analysis, action items). Use when production is down, an alert needs assessment, or after resolution to document lessons learned.

Assess incident severity (SEV1-4) and identify affected systems and users
Draft internal status updates and customer communications with consistent messaging
Track incident timeline and confirm resolution status
Generate blameless postmortem documents with 5-why root cause analysis
Create action items with owners and priorities for follow-up

How to install incident-response

npx skills add https://github.com/anthropics/knowledge-work-plugins --skill incident-response

Claude Code

Cursor

Windsurf

Cline

How to use incident-response

1.Run `/incident-response new [description]` with incident details to start triage phase
2.Assess severity level (SEV1-4) and assign roles (incident commander, communications, responders)
3.Use `/incident-response update [status]` to post status updates at regular cadence during mitigation
4.Document timeline of events and actions taken as incident progresses
5.Run `/incident-response postmortem` after resolution to generate postmortem document with root cause analysis and action items

Use cases

Good for

Production outage requiring immediate triage and all-hands response
Degraded feature affecting subset of users needing severity classification and status updates
Post-incident postmortem writing to document timeline, root cause, and preventive actions
Mid-incident status communication to stakeholders and customers
Alert assessment to determine if incident warrants formal response workflow

Who it's for

On-call engineers and incident commanders
DevOps and SRE teams managing production systems
Engineering managers conducting postmortem reviews
Customer support teams communicating during incidents

incident-response FAQ

When should I use SEV1 vs SEV2?

SEV1 is for service-wide outages affecting all users requiring immediate all-hands response. SEV2 is for major feature degradation affecting many users requiring response within 15 minutes.

How often should I post status updates?

Provide updates at regular cadence during active incident. Include what's happening, who's affected, what actions are being taken, and when the next update is expected.

What makes a postmortem blameless?

Focus on systems, processes, and contributing factors rather than individual mistakes. Use the 5-why framework to identify root causes and systemic improvements.

Can this integrate with my monitoring tools?

Yes, if monitoring connectors are available, the skill can pull alert details and metrics. Check CONNECTORS.md for available integrations.

What should action items from postmortem include?

Each action item should have a clear description, assigned owner, priority level (P0/P1/P2), and due date for tracking and follow-up.

Full instructions (SKILL.md)

Source of truth, from anthropics/knowledge-work-plugins.

name: incident-response description: 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. argument-hint: "<incident description or alert>"

/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.