Skills anthropics knowledge-work-plugins
incident-response
- Use it when:
- Production is down, an alert needs a severity, you owe a mid-incident update, or it's time for the postmortem.
- It does:
- Rates severity SEV1 to SEV4, assigns roles, drafts internal and customer updates, tracks mitigation and the timeline, then writes the postmortem.
- You get:
- Status updates in a fixed format, and a blameless postmortem with impact, timeline, root cause, five whys, action items with owners and lessons.
- With connectors:
- It pulls alerts and metrics, posts updates to your incident channel, creates a war room, and pages on-call through PagerDuty or Opsgenie.
- Runs:
- As /incident-response new, update or postmortem; with no mode it asks what phase the incident is in.
- Part of:
- The engineering plugin of Anthropic's knowledge-work plugins.
With chat or incident-management connectors, it posts status updates to your incident channel, creates a war-room channel, creates or updates incidents in PagerDuty or Opsgenie and pages on-call responders.
TL;DR
A four-phase incident command from the engineering plugin of Anthropic's knowledge-work plugins. Triage rates severity, from SEV1 (service down for all users, an immediate all-hands response) to SEV4 (cosmetic, next business day), identifies the affected systems and users, and assigns an incident commander, communications and responders. Communicate drafts the internal status update and any customer message and sets up a war room and an update cadence. Mitigate records the steps taken and the timeline and confirms resolution. Postmortem writes a blameless document: summary, impact, a UTC timeline, root cause, five whys, what went well and poorly, action items with owner, priority and due date, and lessons learned. Status updates follow one template: severity, a status from investigating to resolved, impact, what's known, actions taken, next steps and a timeline. Updates stay factual and start before all the facts are in, and postmortems focus on systems and processes, not people. With monitoring, incident management or chat connected, it pulls alert details and metrics, creates or updates the incident, pages on-call and posts updates to the incident channel.
Summarizes the skill at ab4cb1c.
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill incident-response skills.sh pageSource on GitHubAll skills from anthropics/knowledge-work-plugins
- Total Downloads
- 6,000 on skills.sh, Nov 9, 2026
- Repo stars
- 35,234 anthropics/knowledge-work-plugins
- First seen
- Feb 24, 2026 on skills.sh
Weekly values
| Week to | Installs |
|---|---|
| Sep 21 | 99 |
| Sep 28 | 65 |
| Oct 5 | 52 |
| Oct 12 | 75 |
| Oct 19 | 72 |
| Oct 26 | 62 |
| Nov 2 | 62 |
| Nov 9 | 66 |
| Category |
Deploy, provision, observe and debug cloud apps. Articles, docs, internal comms, research write-ups and prose that doesn't read as generated. Everything for building software: planning, coding, debugging, design, frameworks, cloud, agents and skills. |
|---|---|
| Type |
A multi-step process the agent follows: interview, debug, run a TDD loop, review. |
| Effect |
Its own steps change something outside your machine: post, send, deploy, provision, file issues, drive a website, or upload data to a service. |
| Needs |
Instructions only. Works in any agent that supports skills. |
| Publisher |
A verified publisher on skills.sh, or the company or maintainer behind the product the skill operates. |
| Topics |
SKILL.md
From anthropics/knowledge-work-plugins at ab4cb1c. Checked daily, last changed Nov 6, 2026.
Frontmatter
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.