New: Earn 20% as an AgentAlley affiliate. Share your link and earn on every sale you refer. Join now New: Earn 20% as an affiliate. Join now

Comprehensive incident response framework from detection

Incident Commander Skill

by alirezarezvani · MIT license · ★ 26,349 on GitHub · updated Aug 30

Incident Commander Skill cover

Comprehensive incident response framework from detection through resolution and post-incident review. Battle-tested SRE/DevOps practices: severity classification, timeline reconstruction, structured post-incident analysis.

---
name: "incident-commander"
description: "Comprehensive incident response framework from detection through resolution and post-incident review. Battle-tested SRE/DevOps practices: severity classification, timeline reconstruction, structured post-incident analysis. Use when declaring an incident, coordinating multi-team response during an outage, leading a post-mortem, or setting up on-call practices for a new service."
---

# Incident Commander Skill

**Category:** Engineering Team  
**Tier:** POWERFUL  
**Author:** Claude Skills Team  
**Version:** 1.0.0  
**Last Updated:** February 2026

## Overview

Incident response framework for **availability/reliability incidents** (outages, degradations, failed deploys): severity classification, timeline reconstruction, and post-incident review.

**This is NOT security incident triage.** For security events (ransomware, intrusion, data exfiltration, IOC analysis, NIST SP 800-61 forensics), route to `incident-response`. Both skills use SEV1-SEV4 labels; this one scores operational impact (users, revenue, SLA), while `incident-response` classifies attack types and forensic handling.

Overview

Category: Engineering Team Tier: POWERFUL Author: Claude Skills Team Version: 1.0.0 Last Updated: February 2026

What you get

  • Automated Severity ClassificationIntelligent incident triage based on impact and urgency metrics
  • Timeline ReconstructionTransform scattered logs and events into coherent incident narratives
  • Post-Incident Review GenerationStructured PIRs with multiple RCA frameworks
  • Communication TemplatesPre-built templates for stakeholder updates and escalations
  • Runbook IntegrationGenerate actionable runbooks from incident patterns
Manual install (npx, ZIP)
Claude Codenpx skills add alirezarezvani/claude-skills --skill incident-commander -g -a claude-code
Claude Code (manual)mkdir -p ~/.claude/skills && curl -sL https://codeload.github.com/alirezarezvani/claude-skills/tar.gz/19392f7a0826 \ | tar -xz -C ~/.claude/skills --strip-components=3 claude-skills-19392f7a0826/engineering-team/skills/incident-commander
Windows (PowerShell)New-Item -ItemType Directory -Force "$HOME\.claude\skills" | Out-Null; Invoke-WebRequest "https://m.agentalley.io/zip/60fe329d6f3323a9f22d/incident-commander.zip" -OutFile "$env:TEMP\incident-commander.zip"; Expand-Archive "$env:TEMP\incident-commander.zip" -DestinationPath "$HOME\.claude\skills" -Force
Claude.ai / desktopDownload the ZIP and upload it under Settings → Capabilities → Skills.
Codex, Cursor, other agentsPoint them at SKILL.md. The other files are plain text.

Connects with Agent Alley MCP · agentalley.io/mcp

Files included

  • SKILL.md14.9 KB
  • README.md7.4 KB
  • assets/8 files · 37.2 KB
  • expected_outputs/4 files · 9.2 KB
  • references/6 files · 93.9 KB
  • scripts/3 files · 141.3 KB
Read the files here
alirezarezvani/19392f723 files
SKILL.md
Show the full text472 lines

Incident Commander Skill

Category: Engineering Team
Tier: POWERFUL
Author: Claude Skills Team
Version: 1.0.0
Last Updated: February 2026

Overview

Incident response framework for availability/reliability incidents (outages, degradations, failed deploys): severity classification, timeline reconstruction, and post-incident review.

This is NOT security incident triage. For security events (ransomware, intrusion, data exfiltration, IOC analysis, NIST SP 800-61 forensics), route to incident-response. Both skills use SEV1-SEV4 labels; this one scores operational impact (users, revenue, SLA), while incident-response classifies attack types and forensic handling.

Key Features

  • Automated Severity Classification - Intelligent incident triage based on impact and urgency metrics
  • Timeline Reconstruction - Transform scattered logs and events into coherent incident narratives
  • Post-Incident Review Generation - Structured PIRs with multiple RCA frameworks
  • Communication Templates - Pre-built templates for stakeholder updates and escalations
  • Runbook Integration - Generate actionable runbooks from incident patterns

Skills Included

Core Tools
  1. Incident Classifier (incident_classifier.py)

    • Analyzes incident descriptions and outputs severity levels
    • Recommends response teams and initial actions
    • Generates communication templates based on severity
  2. Timeline Reconstructor (timeline_reconstructor.py)

    • Processes timestamped events from multiple sources
    • Reconstructs chronological incident timeline
    • Identifies gaps and provides duration analysis
  3. PIR Generator (pir_generator.py)

    • Creates comprehensive Post-Incident Review documents
    • Applies multiple RCA frameworks (5 Whys, Fishbone, Timeline)
    • Generates actionable follow-up items

Incident Response Framework

Severity Classification System
SEV1 - Critical Outage

Definition: Complete service failure affecting all users or critical business functions

Characteristics:

  • Customer-facing services completely unavailable
  • Data loss or corruption affecting users
  • Security breaches with customer data exposure
  • Revenue-generating systems down
  • SLA violations with financial penalties

Response Requirements:

  • Immediate escalation to on-call engineer
  • Incident Commander assigned within 5 minutes
  • Executive notification within 15 minutes
  • Public status page update within 15 minutes
  • War room established
  • All hands on deck if needed

Communication Frequency: Every 15 minutes until resolution

SEV2 - Major Impact

Definition: Significant degradation affecting subset of users or non-critical functions

Characteristics:

  • Partial service degradation (>25% of users affected)
  • Performance issues causing user frustration
  • Non-critical features unavailable
  • Internal tools impacting productivity
  • Data inconsistencies not affecting user experience

Response Requirements:

  • On-call engineer response within 15 minutes
  • Incident Commander assigned within 30 minutes
  • Status page update within 30 minutes
  • Stakeholder notification within 1 hour
  • Regular team updates

Communication Frequency: Every 30 minutes during active response

SEV3 - Minor Impact

Definition: Limited impact with workarounds available

Characteristics:

  • Single feature or component affected
  • <25% of users impacted
  • Workarounds available
  • Performance degradation not significantly impacting UX
  • Non-urgent monitoring alerts

Response Requirements:

  • Response within 2 hours during business hours
  • Next business day response acceptable outside hours
  • Internal team notification
  • Optional status page update

Communication Frequency: At key milestones only

SEV4 - Low Impact

Definition: Minimal impact, cosmetic issues, or planned maintenance

Characteristics:

  • Cosmetic bugs
  • Documentation issues
  • Logging or monitoring gaps
  • Performance issues with no user impact
  • Development/test environment issues

Response Requirements:

  • Response within 1-2 business days
  • Standard ticket/issue tracking
  • No special escalation required

Communication Frequency: Standard development cycle updates

Incident Commander Role
Primary Responsibilities
  1. Command and Control

    • Own the incident response process
    • Make critical decisions about resource allocation
    • Coordinate between technical teams and stakeholders
    • Maintain situational awareness across all response streams
  2. Communication Hub

    • Provide regular updates to stakeholders
    • Manage external communications (status pages, customer notifications)
    • Facilitate effective communication between response teams
    • Shield responders from external distractions
  3. Process Management

    • Ensure proper incident tracking and documentation
    • Drive toward resolution while maintaining quality
    • Coordinate handoffs between team members
    • Plan and execute rollback strategies if needed
  4. Post-Incident Leadership

    • Ensure thorough post-incident reviews are conducted
    • Drive implementation of preventive measures
    • Share learnings with broader organization
Decision-Making Framework

Emergency Decisions (SEV1/2):

  • Incident Commander has full authority
  • Bias toward action over analysis
  • Document decisions for later review
  • Consult subject matter experts but don't get blocked

Resource Allocation:

  • Can pull in any necessary team members
  • Authority to escalate to senior leadership
  • Can approve emergency spend for external resources
  • Make call on communication channels and timing

Technical Decisions:

  • Lean on technical leads for implementation details
  • Make final calls on trade-offs between speed and risk
  • Approve rollback vs. fix-forward strategies
  • Coordinate testing and validation approaches
Communication Templates
Initial Incident Notification (SEV1/2)
Subject: [SEV{severity}] {Service Name} - {Brief Description}

Incident Details:
- Start Time: {timestamp}
- Severity: SEV{level}
- Impact: {user impact description}
- Current Status: {investigating/mitigating/resolved}

Technical Details:
- Affected Services: {service list}
- Symptoms: {what users are experiencing}
- Initial Assessment: {suspected root cause if known}

Response Team:
- Incident Commander: {name}
- Technical Lead: {name}
- SMEs Engaged: {list}

Next Update: {timestamp}
Status Page: {link}
War Room: {bridge/chat link}

---
{Incident Commander Name}
{Contact Information}
Executive Summary (SEV1)
Subject: URGENT - Customer-Impacting Outage - {Service Name}

Executive Summary:
{2-3 sentence description of customer impact and business implications}

Key Metrics:
- Time to Detection: {X minutes}
- Time to Engagement: {X minutes} 
- Estimated Customer Impact: {number/percentage}
- Current Status: {status}
- ETA to Resolution: {time or "investigating"}

Leadership Actions Required:
- [ ] Customer communication approval
- [ ] PR/Communications coordination  
- [ ] Resource allocation decisions
- [ ] External vendor engagement

Incident Commander: {name} ({contact})
Next Update: {time}

---
This is an automated alert from our incident response system.
Customer Communication Template
We are currently experiencing {brief description of issue} affecting {scope of impact}. 

Our engineering team was alerted at {time} and is actively working to resolve the issue. We will provide updates every {frequency} until resolved.

What we know:
- {factual statement of impact}
- {factual statement of scope}
- {brief status of response}

What we're doing:
- {primary response action}
- {secondary response action}

Workaround (if available):
{workaround steps or "No workaround currently available"}

We apologize for the inconvenience and will share more information as it becomes available.

Next update: {time}
Status page: {link}
Stakeholder Management
Stakeholder Classification

Internal Stakeholders:

  • Engineering Leadership - Technical decisions and resource allocation
  • Product Management - Customer impact assessment and feature implications
  • Customer Support - User communication and support ticket management
  • Sales/Account Management - Customer relationship management for enterprise clients
  • Executive Team - Business impact decisions and external communication approval
  • Legal/Compliance - Regulatory reporting and liability assessment

External Stakeholders:

  • Customers - Service availability and impact communication
  • Partners - API availability and integration impacts
  • Vendors - Third-party service dependencies and support escalation
  • Regulators - Compliance reporting for regulated industries
  • Public/Media - Transparency for public-facing outages
Communication Cadence by Stakeholder
Stakeholder SEV1 SEV2 SEV3 SEV4
Engineering Leadership Real-time 30min 4hrs Daily
Executive Team 15min 1hr EOD Weekly
Customer Support Real-time 30min 2hrs As needed
Customers 15min 1hr Optional None
Partners 30min 2hrs Optional None
Runbook Generation Framework
Dynamic Runbook Components
  1. Detection Playbooks

    • Monitoring alert definitions
    • Triage decision trees
    • Escalation trigger points
    • Initial response actions
  2. Response Playbooks

    • Step-by-step mitigation procedures
    • Rollback instructions
    • Validation checkpoints
    • Communication checkpoints
  3. Recovery Playbooks

    • Service restoration procedures
    • Data consistency checks
    • Performance validation
    • User notification processes
Runbook Template Structure
# {Service/Component} Incident Response Runbook

## Quick Reference
- **Severity Indicators:** {list of conditions for each severity level}
- **Key Contacts:** {on-call rotations and escalation paths}
- **Critical Commands:** {list of emergency commands with descriptions}

## Detection
### Monitoring Alerts
- {Alert name}: {description and thresholds}
- {Alert name}: {description and thresholds}

### Manual Detection Signs
- {Symptom}: {what to look for and where}
- {Symptom}: {what to look for and where}

## Initial Response (0-15 minutes)
1. **Assess Severity**
   - [ ] Check {primary metric}
   - [ ] Verify {secondary indicator}
   - [ ] Classify as SEV{level} based on {criteria}

2. **Establish Command**
   - [ ] Page Incident Commander if SEV1/2
   - [ ] Create incident tracking ticket
   - [ ] Join war room: {link/bridge info}

3. **Initial Investigation**
   - [ ] Check recent deployments: {deployment log location}
   - [ ] Review error logs: {log location and queries}
   - [ ] Verify dependencies: {dependency check commands}

## Mitigation Strategies
### Strategy 1: {Name}
**Use when:** {conditions}
**Steps:**
1. {detailed step with commands}
2. {detailed step with expected outcomes}
3. {validation step}

**Rollback Plan:**
1. {rollback step}
2. {verification step}

### Strategy 2: {Name}
{similar structure}

## Recovery and Validation
1. **Service Restoration**
   - [ ] {restoration step}
   - [ ] Wait for {metric} to return to normal
   - [ ] Validate end-to-end functionality

2. **Communication**
   - [ ] Update status page
   - [ ] Notify stakeholders
   - [ ] Schedule PIR

## Common Pitfalls
- **{Pitfall}:** {description and how to avoid}
- **{Pitfall}:** {description and how to avoid}

## Reference Information
→ See references/reference-information.md for details

## Usage Examples

### Example 1: Database Connection Pool Exhaustion

```bash
# Classify the incident
echo '{"description": "Users reporting 500 errors, database connections timing out", "affected_users": "80%", "business_impact": "high"}' | python scripts/incident_classifier.py

# Reconstruct timeline from logs
python scripts/timeline_reconstructor.py --input assets/sample_timeline_events.json --output timeline.md

# Generate PIR after resolution
python scripts/pir_generator.py --incident assets/sample_incident_data.json --timeline timeline.md --output pir.md
Example 2: API Rate Limiting Incident
# Quick classification from stdin
echo "API rate limits causing customer API calls to fail" | python scripts/incident_classifier.py --format text

# Build timeline from multiple sources
python scripts/timeline_reconstructor.py --input assets/simple_timeline_events.json --detect-phases --gap-analysis

# Generate comprehensive PIR
python scripts/pir_generator.py --incident assets/sample_incident_pir_data.json --rca-method fishbone --action-items

Best Practices

During Incident Response
  1. Maintain Calm Leadership

    • Stay composed under pressure
    • Make decisive calls with incomplete information
    • Communicate confidence while acknowledging uncertainty
  2. Document Everything

    • All actions taken and their outcomes
    • Decision rationale, especially for controversial calls
    • Timeline of events as they happen
  3. Effective Communication

    • Use clear, jargon-free language
    • Provide regular updates even when there's no new information
    • Manage stakeholder expectations proactively
  4. Technical Excellence

    • Prefer rollbacks to risky fixes under pressure
    • Validate fixes before declaring resolution
    • Plan for secondary failures and cascading effects
Post-Incident
  1. Blameless Culture

    • Focus on system failures, not individual mistakes
    • Encourage honest reporting of what went wrong
    • Celebrate learning and improvement opportunities
  2. Action Item Discipline

    • Assign specific owners and due dates
    • Track progress publicly
    • Prioritize based on risk and effort
  3. Knowledge Sharing

    • Share PIRs broadly within the organization
    • Update runbooks based on lessons learned
    • Conduct training sessions for common failure modes
  4. Continuous Improvement

    • Look for patterns across multiple incidents
    • Invest in tooling and automation
    • Regularly review and update processes

Integration with Existing Tools

Monitoring and Alerting
  • PagerDuty/Opsgenie integration for escalation
  • Datadog/Grafana for metrics and dashboards
  • ELK/Splunk for log analysis and correlation
Communication Platforms
  • Slack/Teams for war room coordination
  • Zoom/Meet for video bridges
  • Status page providers (Statuspage.io, etc.)
Documentation Systems
  • Confluence/Notion for PIR storage
  • GitHub/GitLab for runbook version control
  • JIRA/Linear for action item tracking
Change Management
  • CI/CD pipeline integration
  • Deployment tracking systems
  • Feature flag platforms for quick rollbacks
1---
2name: "incident-commander"
3description: "Comprehensive incident response framework from detection through resolution and post-incident review. Battle-tested SRE/DevOps practices: severity classification, timeline reconstruction, structured post-incident analysis. Use when declaring an incident, coordinating multi-team response during an outage, leading a post-mortem, or setting up on-call practices for a new service."
4---
5 
6# Incident Commander Skill
7 
8**Category:** Engineering Team
9**Tier:** POWERFUL
10**Author:** Claude Skills Team
11**Version:** 1.0.0
12**Last Updated:** February 2026
13 
14## Overview
15 
16Incident response framework for **availability/reliability incidents** (outages, degradations, failed deploys): severity classification, timeline reconstruction, and post-incident review.
17 
18**This is NOT security incident triage.** For security events (ransomware, intrusion, data exfiltration, IOC analysis, NIST SP 800-61 forensics), route to `incident-response`. Both skills use SEV1-SEV4 labels; this one scores operational impact (users, revenue, SLA), while `incident-response` classifies attack types and forensic handling.
19 
20## Key Features
21 
22- **Automated Severity Classification** - Intelligent incident triage based on impact and urgency metrics
23- **Timeline Reconstruction** - Transform scattered logs and events into coherent incident narratives
24- **Post-Incident Review Generation** - Structured PIRs with multiple RCA frameworks
25- **Communication Templates** - Pre-built templates for stakeholder updates and escalations
26- **Runbook Integration** - Generate actionable runbooks from incident patterns
27 
28## Skills Included
29 
30### Core Tools
31 
321. **Incident Classifier** (`incident_classifier.py`)
33 - Analyzes incident descriptions and outputs severity levels
34 - Recommends response teams and initial actions
35 - Generates communication templates based on severity
36 
372. **Timeline Reconstructor** (`timeline_reconstructor.py`)
38 - Processes timestamped events from multiple sources
39 - Reconstructs chronological incident timeline
40 - Identifies gaps and provides duration analysis
41 
423. **PIR Generator** (`pir_generator.py`)
43 - Creates comprehensive Post-Incident Review documents
44 - Applies multiple RCA frameworks (5 Whys, Fishbone, Timeline)
45 - Generates actionable follow-up items
46 
47## Incident Response Framework
48 
49### Severity Classification System
50 
51#### SEV1 - Critical Outage
52**Definition:** Complete service failure affecting all users or critical business functions
53 
54**Characteristics:**
55- Customer-facing services completely unavailable
56- Data loss or corruption affecting users
57- Security breaches with customer data exposure
58- Revenue-generating systems down
59- SLA violations with financial penalties
60 
61**Response Requirements:**
62- Immediate escalation to on-call engineer
63- Incident Commander assigned within 5 minutes
64- Executive notification within 15 minutes
65- Public status page update within 15 minutes
66- War room established
67- All hands on deck if needed
68 
69**Communication Frequency:** Every 15 minutes until resolution
70 
71#### SEV2 - Major Impact
72**Definition:** Significant degradation affecting subset of users or non-critical functions
73 
74**Characteristics:**
75- Partial service degradation (>25% of users affected)
76- Performance issues causing user frustration
77- Non-critical features unavailable
78- Internal tools impacting productivity
79- Data inconsistencies not affecting user experience
80 
81**Response Requirements:**
82- On-call engineer response within 15 minutes
83- Incident Commander assigned within 30 minutes
84- Status page update within 30 minutes
85- Stakeholder notification within 1 hour
86- Regular team updates
87 
88**Communication Frequency:** Every 30 minutes during active response
89 
90#### SEV3 - Minor Impact
91**Definition:** Limited impact with workarounds available
92 
93**Characteristics:**
94- Single feature or component affected
95- <25% of users impacted
96- Workarounds available
97- Performance degradation not significantly impacting UX
98- Non-urgent monitoring alerts
99 
100**Response Requirements:**
101- Response within 2 hours during business hours
102- Next business day response acceptable outside hours
103- Internal team notification
104- Optional status page update
105 
106**Communication Frequency:** At key milestones only
107 
108#### SEV4 - Low Impact
109**Definition:** Minimal impact, cosmetic issues, or planned maintenance
110 
111**Characteristics:**
112- Cosmetic bugs
113- Documentation issues
114- Logging or monitoring gaps
115- Performance issues with no user impact
116- Development/test environment issues
117 
118**Response Requirements:**
119- Response within 1-2 business days
120- Standard ticket/issue tracking
121- No special escalation required
122 
123**Communication Frequency:** Standard development cycle updates
124 
125### Incident Commander Role
126 
127#### Primary Responsibilities
128 
1291. **Command and Control**
130 - Own the incident response process
131 - Make critical decisions about resource allocation
132 - Coordinate between technical teams and stakeholders
133 - Maintain situational awareness across all response streams
134 
1352. **Communication Hub**
136 - Provide regular updates to stakeholders
137 - Manage external communications (status pages, customer notifications)
138 - Facilitate effective communication between response teams
139 - Shield responders from external distractions
140 
1413. **Process Management**
142 - Ensure proper incident tracking and documentation
143 - Drive toward resolution while maintaining quality
144 - Coordinate handoffs between team members
145 - Plan and execute rollback strategies if needed
146 
1474. **Post-Incident Leadership**
148 - Ensure thorough post-incident reviews are conducted
149 - Drive implementation of preventive measures
150 - Share learnings with broader organization
151 
152#### Decision-Making Framework
153 
154**Emergency Decisions (SEV1/2):**
155- Incident Commander has full authority
156- Bias toward action over analysis
157- Document decisions for later review
158- Consult subject matter experts but don't get blocked
159 
160**Resource Allocation:**
161- Can pull in any necessary team members
162- Authority to escalate to senior leadership
163- Can approve emergency spend for external resources
164- Make call on communication channels and timing
165 
166**Technical Decisions:**
167- Lean on technical leads for implementation details
168- Make final calls on trade-offs between speed and risk
169- Approve rollback vs. fix-forward strategies
170- Coordinate testing and validation approaches
171 
172### Communication Templates
173 
174#### Initial Incident Notification (SEV1/2)
175 
176```
177Subject: [SEV{severity}] {Service Name} - {Brief Description}
178 
179Incident Details:
180- Start Time: {timestamp}
181- Severity: SEV{level}
182- Impact: {user impact description}
183- Current Status: {investigating/mitigating/resolved}
184 
185Technical Details:
186- Affected Services: {service list}
187- Symptoms: {what users are experiencing}
188- Initial Assessment: {suspected root cause if known}
189 
190Response Team:
191- Incident Commander: {name}
192- Technical Lead: {name}
193- SMEs Engaged: {list}
194 
195Next Update: {timestamp}
196Status Page: {link}
197War Room: {bridge/chat link}
198 
199---
200{Incident Commander Name}
201{Contact Information}
202```
203 
204#### Executive Summary (SEV1)
205 
206```
207Subject: URGENT - Customer-Impacting Outage - {Service Name}
208 
209Executive Summary:
210{2-3 sentence description of customer impact and business implications}
211 
212Key Metrics:
213- Time to Detection: {X minutes}
214- Time to Engagement: {X minutes}
215- Estimated Customer Impact: {number/percentage}
216- Current Status: {status}
217- ETA to Resolution: {time or "investigating"}
218 
219Leadership Actions Required:
220- [ ] Customer communication approval
221- [ ] PR/Communications coordination
222- [ ] Resource allocation decisions
223- [ ] External vendor engagement
224 
225Incident Commander: {name} ({contact})
226Next Update: {time}
227 
228---
229This is an automated alert from our incident response system.
230```
231 
232#### Customer Communication Template
233 
234```
235We are currently experiencing {brief description of issue} affecting {scope of impact}.
236 
237Our engineering team was alerted at {time} and is actively working to resolve the issue. We will provide updates every {frequency} until resolved.
238 
239What we know:
240- {factual statement of impact}
241- {factual statement of scope}
242- {brief status of response}
243 
244What we're doing:
245- {primary response action}
246- {secondary response action}
247 
248Workaround (if available):
249{workaround steps or "No workaround currently available"}
250 
251We apologize for the inconvenience and will share more information as it becomes available.
252 
253Next update: {time}
254Status page: {link}
255```
256 
257### Stakeholder Management
258 
259#### Stakeholder Classification
260 
261**Internal Stakeholders:**
262- **Engineering Leadership** - Technical decisions and resource allocation
263- **Product Management** - Customer impact assessment and feature implications
264- **Customer Support** - User communication and support ticket management
265- **Sales/Account Management** - Customer relationship management for enterprise clients
266- **Executive Team** - Business impact decisions and external communication approval
267- **Legal/Compliance** - Regulatory reporting and liability assessment
268 
269**External Stakeholders:**
270- **Customers** - Service availability and impact communication
271- **Partners** - API availability and integration impacts
272- **Vendors** - Third-party service dependencies and support escalation
273- **Regulators** - Compliance reporting for regulated industries
274- **Public/Media** - Transparency for public-facing outages
275 
276#### Communication Cadence by Stakeholder
277 
278| Stakeholder | SEV1 | SEV2 | SEV3 | SEV4 |
279|-------------|------|------|------|------|
280| Engineering Leadership | Real-time | 30min | 4hrs | Daily |
281| Executive Team | 15min | 1hr | EOD | Weekly |
282| Customer Support | Real-time | 30min | 2hrs | As needed |
283| Customers | 15min | 1hr | Optional | None |
284| Partners | 30min | 2hrs | Optional | None |
285 
286### Runbook Generation Framework
287 
288#### Dynamic Runbook Components
289 
2901. **Detection Playbooks**
291 - Monitoring alert definitions
292 - Triage decision trees
293 - Escalation trigger points
294 - Initial response actions
295 
2962. **Response Playbooks**
297 - Step-by-step mitigation procedures
298 - Rollback instructions
299 - Validation checkpoints
300 - Communication checkpoints
301 
3023. **Recovery Playbooks**
303 - Service restoration procedures
304 - Data consistency checks
305 - Performance validation
306 - User notification processes
307 
308#### Runbook Template Structure
309 
310```markdown
311# {Service/Component} Incident Response Runbook
312 
313## Quick Reference
314- **Severity Indicators:** {list of conditions for each severity level}
315- **Key Contacts:** {on-call rotations and escalation paths}
316- **Critical Commands:** {list of emergency commands with descriptions}
317 
318## Detection
319### Monitoring Alerts
320- {Alert name}: {description and thresholds}
321- {Alert name}: {description and thresholds}
322 
323### Manual Detection Signs
324- {Symptom}: {what to look for and where}
325- {Symptom}: {what to look for and where}
326 
327## Initial Response (0-15 minutes)
3281. **Assess Severity**
329 - [ ] Check {primary metric}
330 - [ ] Verify {secondary indicator}
331 - [ ] Classify as SEV{level} based on {criteria}
332 
3332. **Establish Command**
334 - [ ] Page Incident Commander if SEV1/2
335 - [ ] Create incident tracking ticket
336 - [ ] Join war room: {link/bridge info}
337 
3383. **Initial Investigation**
339 - [ ] Check recent deployments: {deployment log location}
340 - [ ] Review error logs: {log location and queries}
341 - [ ] Verify dependencies: {dependency check commands}
342 
343## Mitigation Strategies
344### Strategy 1: {Name}
345**Use when:** {conditions}
346**Steps:**
3471. {detailed step with commands}
3482. {detailed step with expected outcomes}
3493. {validation step}
350 
351**Rollback Plan:**
3521. {rollback step}
3532. {verification step}
354 
355### Strategy 2: {Name}
356{similar structure}
357 
358## Recovery and Validation
3591. **Service Restoration**
360 - [ ] {restoration step}
361 - [ ] Wait for {metric} to return to normal
362 - [ ] Validate end-to-end functionality
363 
3642. **Communication**
365 - [ ] Update status page
366 - [ ] Notify stakeholders
367 - [ ] Schedule PIR
368 
369## Common Pitfalls
370- **{Pitfall}:** {description and how to avoid}
371- **{Pitfall}:** {description and how to avoid}
372 
373## Reference Information
374→ See references/reference-information.md for details
375 
376## Usage Examples
377 
378### Example 1: Database Connection Pool Exhaustion
379 
380```bash
381# Classify the incident
382echo '{"description": "Users reporting 500 errors, database connections timing out", "affected_users": "80%", "business_impact": "high"}' | python scripts/incident_classifier.py
383 
384# Reconstruct timeline from logs
385python scripts/timeline_reconstructor.py --input assets/sample_timeline_events.json --output timeline.md
386 
387# Generate PIR after resolution
388python scripts/pir_generator.py --incident assets/sample_incident_data.json --timeline timeline.md --output pir.md
389```
390 
391### Example 2: API Rate Limiting Incident
392 
393```bash
394# Quick classification from stdin
395echo "API rate limits causing customer API calls to fail" | python scripts/incident_classifier.py --format text
396 
397# Build timeline from multiple sources
398python scripts/timeline_reconstructor.py --input assets/simple_timeline_events.json --detect-phases --gap-analysis
399 
400# Generate comprehensive PIR
401python scripts/pir_generator.py --incident assets/sample_incident_pir_data.json --rca-method fishbone --action-items
402```
403 
404## Best Practices
405 
406### During Incident Response
407 
4081. **Maintain Calm Leadership**
409 - Stay composed under pressure
410 - Make decisive calls with incomplete information
411 - Communicate confidence while acknowledging uncertainty
412 
4132. **Document Everything**
414 - All actions taken and their outcomes
415 - Decision rationale, especially for controversial calls
416 - Timeline of events as they happen
417 
4183. **Effective Communication**
419 - Use clear, jargon-free language
420 - Provide regular updates even when there's no new information
421 - Manage stakeholder expectations proactively
422 
4234. **Technical Excellence**
424 - Prefer rollbacks to risky fixes under pressure
425 - Validate fixes before declaring resolution
426 - Plan for secondary failures and cascading effects
427 
428### Post-Incident
429 
4301. **Blameless Culture**
431 - Focus on system failures, not individual mistakes
432 - Encourage honest reporting of what went wrong
433 - Celebrate learning and improvement opportunities
434 
4352. **Action Item Discipline**
436 - Assign specific owners and due dates
437 - Track progress publicly
438 - Prioritize based on risk and effort
439 
4403. **Knowledge Sharing**
441 - Share PIRs broadly within the organization
442 - Update runbooks based on lessons learned
443 - Conduct training sessions for common failure modes
444 
4454. **Continuous Improvement**
446 - Look for patterns across multiple incidents
447 - Invest in tooling and automation
448 - Regularly review and update processes
449 
450## Integration with Existing Tools
451 
452### Monitoring and Alerting
453- PagerDuty/Opsgenie integration for escalation
454- Datadog/Grafana for metrics and dashboards
455- ELK/Splunk for log analysis and correlation
456 
457### Communication Platforms
458- Slack/Teams for war room coordination
459- Zoom/Meet for video bridges
460- Status page providers (Statuspage.io, etc.)
461 
462### Documentation Systems
463- Confluence/Notion for PIR storage
464- GitHub/GitLab for runbook version control
465- JIRA/Linear for action item tracking
466 
467### Change Management
468- CI/CD pipeline integration
469- Deployment tracking systems
470- Feature flag platforms for quick rollbacks
471 
472 
View all files on GitHub →

Details

Updated
Aug 30, 2026
License
MIT
Stars on the repo
★ 26,349
Checked
Source
alirezarezvani/claude-skills ↗
Creator
alirezarezvani · 363 listings
View creator

Similar skills

See all →
MCPExpert debugging specialist for errors, test failuresDebugger AgentCloudAI-X/claude-workflow-v2 · by CloudAI-XExpert debugging specialist for errors, test failures, crashes, segmentation faults, memory leaks, timeouts, race conditions, deadlocks, and unexpected behavior. Use PROACTIVELY when encountering any error, exception, or failing test. Performs systematic root cause analysis.★ 1.4k GitHub starsSkillEncountering any bug, test failure, or unexpected behaviorSystematic debuggingobra/superpowers · by obraUse when encountering any bug, test failure, or unexpected behavior, before proposing fixes★ 290k GitHub starsSkillRequires running verification commands and confirming outputVerification before completionobra/superpowers · by obraUse when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always★ 290k GitHub starsSkillGuides systematic root-cause debuggingDebugging and error recoveryaddyosmani/agent-skills · by addyosmaniGuides systematic root-cause debugging. Use when tests fail, builds break, something that worked yesterday broke, behavior doesn't match expectations, or you encounter any unexpected error. Use when you need to figure out what broke and why — a systematic approach to finding and fixing the root cause rather than guessing.★ 98.7k GitHub starsSkillMaster systematic debugging techniques, profiling toolsDebugging strategieswshobson/agents · by wshobsonMaster systematic debugging techniques, profiling tools, and root cause analysis to efficiently track down bugs across any codebase or technology stack. Use when investigating bugs, performance issues, or unexpected behavior.★ 39.9k GitHub starsSkillMaster error handling patterns across languages includingwshobson/agents · by wshobsonMaster error handling patterns across languages including exceptions, Result types, error propagation, and graceful degradation to build resilient applications. Use when implementing error handling, designing APIs, or improving application reliability.★ 39.9k GitHub stars

More from alirezarezvani

SkillResume a paused experiment/ar:ar-resume — Resume Experimentalirezarezvani/claude-skills · by alirezarezvaniResume a paused experiment. Checkout the experiment branch, read results history, continue iterating. Use when the user runs /ar:ar-resume or asks to pick up a previously started autoresearch experiment.★ 26.3k GitHub starsSkillShow experiment dashboard with results, active loops/ar:ar-status — Experiment Dashboardalirezarezvani/claude-skills · by alirezarezvaniShow experiment dashboard with results, active loops, and progress. Use when the user runs /ar:ar-status or asks how an autoresearch experiment is going.★ 26.3k GitHub starsSkillStart an autonomous experiment loop with user-selected/ar:loop — Autonomous Experiment Loopalirezarezvani/claude-skills · by alirezarezvaniStart an autonomous experiment loop with user-selected interval (10min, 1h, daily, weekly, monthly). Uses CronCreate for scheduling. Use when the user runs /ar:loop or asks to run an autoresearch experiment continuously on a schedule.★ 26.3k GitHub starsSkillRun a single experiment iteration/ar:run — Single Experiment Iterationalirezarezvani/claude-skills · by alirezarezvaniRun a single experiment iteration. Edit the target file, evaluate, keep or discard. Use when the user runs /ar:run or asks for one manual autoresearch iteration.★ 26.3k GitHub starsSkillSet up a new autoresearch experiment interactively/ar:setup — Create New Experimentalirezarezvani/claude-skills · by alirezarezvaniSet up a new autoresearch experiment interactively. Collects domain, target file, eval command, metric, direction, and evaluator. Use when the user runs /ar:setup or asks to start optimizing a file with the autoresearch loop.★ 26.3k GitHub starsSkill/cs:boardroom <brief/cs:boardroom — Multi-Role Boardroom Deliberationalirezarezvani/claude-skills · by alirezarezvani/cs:boardroom <brief> — 6-phase multi-role deliberation across the C-suite with Phase 2 isolation, critic pre-screen, and synthesis. Outputs a board memo. Use when a decision spans multiple executive domains — e.g. a pricing change touching finance, positioning, and product, or a raise-vs-cut runway call.★ 26.3k GitHub stars