Install any skill in seconds. Free to start, no credit card required.
Get Started Free →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.
.claude/skills/alirezarezvani-incident-commander/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-06 | ✗→✓ | ▲ Improved | 166% | 0% |
| case-07 | ✗→✓ | ▲ Improved | 231% | 0% |
| case-08 | ✗→✓ | ▲ Improved | 173% | 0% |
| case-10 | ✗→✓ | ▲ Improved | 155% | 0% |
| case-11 | ✗→✓ | ▲ Improved | 144% | 0% |
Category: Engineering Team Tier: POWERFUL Author: Claude Skills Team Version: 1.0.0 Last Updated: February 2026
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.
incident_classifier.py)timeline_reconstructor.py)pir_generator.py)Definition: Complete service failure affecting all users or critical business functions
Characteristics:
Response Requirements:
Communication Frequency: Every 15 minutes until resolution
Definition: Significant degradation affecting subset of users or non-critical functions
Characteristics:
Response Requirements:
Communication Frequency: Every 30 minutes during active response
Definition: Limited impact with workarounds available
Characteristics:
Response Requirements:
Communication Frequency: At key milestones only
Definition: Minimal impact, cosmetic issues, or planned maintenance
Characteristics:
Response Requirements:
Communication Frequency: Standard development cycle updates
Emergency Decisions (SEV1/2):
Resource Allocation:
Technical Decisions:
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}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.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}Internal Stakeholders:
External Stakeholders:
| 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 |
markdown# {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
echo '{"description": "Users reporting 500 errors, database connections timing out", "affected_users": "80%", "business_impact": "high"}' | python scripts/incident_classifier.py
python scripts/timeline_reconstructor.py --input assets/sample_timeline_events.json --output timeline.md
python scripts/pir_generator.py --incident assets/sample_incident_data.json --timeline timeline.md --output pir.md
### Example 2: API Rate Limiting Incident
echo "API rate limits causing customer API calls to fail" | python scripts/incident_classifier.py --format text
python scripts/timeline_reconstructor.py --input assets/simple_timeline_events.json --detect-phases --gap-analysis
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| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-01 | fail→fail | 10,956 | 8,128 | -26% | 1 | 1 | 0% | 1,918 | 4,777 | +149% | 0 | 0 | — |
case-02 | pass→pass | 15,516 | 13,537 | -13% | 1 | 1 | 0% | 2,720 | 5,641 | +107% | 0 | 0 | — |
case-03 | pass→pass | 14,781 | 14,404 | -3% | 1 | 1 | 0% | 2,595 | 5,788 | +123% | 0 | 0 | — |
case-04 | pass→pass | 15,055 | 11,596 | -23% | 1 | 1 | 0% | 2,700 | 5,219 | +93% | 0 | 0 | — |
case-05 | pass→pass | 8,973 | 4,070 | -55% | 1 | 1 | 0% | 1,737 | 4,123 | +137% | 0 | 0 | — |
case-06 | fail→pass | 9,789 | 6,074 | -38% | 1 | 1 | 0% | 1,654 | 4,399 | +166% | 0 | 0 | — |
case-16 | pass→pass | 10,956 | 2,223 | -80% | 1 | 1 | 0% | 2,088 | 3,779 | +81% | 0 | 0 | — |
case-07 | fail→pass | 6,541 | 3,554 | -46% | 1 | 1 | 0% | 1,218 | 4,027 | +231% | 0 | 0 | — |
case-08 | fail→pass | 8,346 | 3,635 | -56% | 1 | 1 | 0% | 1,457 | 3,982 | +173% | 0 | 0 | — |
case-09 | fail→fail | 7,724 | 8,027 | +4% | 1 | 1 | 0% | 1,360 | 4,764 | +250% | 0 | 0 | — |
case-10 | fail→pass | 8,690 | 2,450 | -72% | 1 | 1 | 0% | 1,475 | 3,754 | +155% | 0 | 0 | — |
case-11 | fail→pass | 9,073 | 4,049 | -55% | 1 | 1 | 0% | 1,660 | 4,058 | +144% | 0 | 0 | — |
case-12 | pass→pass | 8,933 | 4,777 | -47% | 1 | 1 | 0% | 1,649 | 4,110 | +149% | 0 | 0 | — |
case-13 | fail→pass | 14,499 | 2,989 | -79% | 1 | 1 | 0% | 2,901 | 3,722 | +28% | 0 | 0 | — |
case-14 | pass→pass | 5,596 | 1,648 | -71% | 1 | 1 | 0% | 1,127 | 3,666 | +225% | 0 | 0 | — |
case-15 | fail→pass | 4,160 | 1,625 | -61% | 1 | 1 | 0% | 823 | 3,572 | +334% | 0 | 0 | — |
case-17 | fail→pass | 9,296 | 1,942 | -79% | 1 | 1 | 0% | 1,795 | 3,688 | +105% | 0 | 0 | — |
case-18 | fail→pass | 8,660 | 3,304 | -62% | 1 | 1 | 0% | 1,538 | 3,868 | +151% | 0 | 0 | — |
case-19 | pass→pass | 10,393 | 12,997 | +25% | 1 | 1 | 0% | 1,823 | 5,573 | +206% | 0 | 0 | — |
case-20 | pass→pass | 8,902 | 2,322 | -74% | 1 | 1 | 0% | 1,661 | 3,699 | +123% | 0 | 0 | — |
case-21 | fail→pass | 7,919 | 3,900 | -51% | 1 | 1 | 0% | 1,433 | 4,026 | +181% | 0 | 0 | — |
case-22 | pass→pass | 13,265 | 7,842 | -41% | 1 | 1 | 0% | 2,312 | 4,620 | +100% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted. The headline lift of +45 percentage points is the difference between those two pass rates over the 22 comparable cases.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.