PromptShop

Incident Response

This skill helps manage incidents from detection to postmortem, guiding users through triage, communication, mitigation, and postmortem phases. It assists in...

Install

npx promptshop add incident-response

Details

What This Skill Does

This skill helps manage incidents from detection to postmortem, guiding users through triage, communication, mitigation, and postmortem phases. It assists in assessing severity, assigning roles, drafting communications, and documenting mitigation steps. It's useful for on-call engineers and incident commanders to effectively handle and resolve incidents.

When to Use

Start a new incident with a description. Post a status update during an incident. Generate a postmortem document after resolution. Assess the severity of an incident. Assign roles to incident responders. Document mitigation steps taken during an incident.

Key Features

Guides through triage, communication, mitigation, and postmortem. Assists in assessing incident severity. Helps draft internal and customer communications. Provides a framework for documenting mitigation steps. Facilitates timeline reconstruction. Supports blameless postmortem analysis.

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

LevelCriteriaResponse Time
SEV1Service down, all users affectedImmediate, all-hands
SEV2Major feature degraded, many users affectedWithin 15 min
SEV3Minor feature issue, some users affectedWithin 1 hour
SEV4Cosmetic or low-impact issueNext 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

TimeEvent
[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

Why did [symptom]? → [Because...] Why did [cause 1]? → [Because...] Why did [cause 2]? → [Because...] Why did [cause 3]? → [Because...] Why did [cause 4]? → [Root cause]

What Went Well

[Things that worked]

What Went Poorly

[Things that didn't work]

Action Items

ActionOwnerPriorityDue 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 Pager Duty/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./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

LevelCriteriaResponse Time
SEV1Service down, all users affectedImmediate, all-hands