Incident Commander
Draft a severity-tagged incident report with executive summary, customer impact, and UTC timeline while you are still firefighting production.
Overview
Incident Commander is an agent skill for the Operate phase that structures live production incident reports with severity, impact metrics, and an IC timeline.
Install
npx skills add https://github.com/alirezarezvani/claude-skills --skill incident-commanderWhat is this skill?
- SEV1–SEV4 incident header with status lifecycle (Active → Mitigated → Resolved).
- Impact table: duration, affected users, failed transactions, revenue, data loss, SLA %, regions, services.
- UTC timeline rows for Detection, Declaration, Investigation, Mitigation, Resolution, Closure.
- Key decision points section for IC audit trail and executive readability.
- Customer-facing impact section separate from internal jargon.
- SEV1–SEV4 severity scale in the report header
- Six standard timeline phases from Detection through Closure
Adoption & trust: 536 installs on skills.sh; 17.5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are mid-outage with scattered notes in chat and no executive-ready incident document.
Who is it for?
Indie SaaS founders wearing the IC hat who need consistent SEV-labeled comms during customer-visible failures.
Skip if: Greenfield threat modeling or pre-launch pen tests—use before production has users and measurable SLA impact.
When should I use this skill?
User is declaring, managing, or closing a production incident and needs a formal IC report.
What do I get? / Deliverables
You produce a complete INC-style report with impact tables and decision log entries ready for stakeholders and post-incident review.
- Filled incident report markdown with executive summary and impact statement
- UTC timeline and key decision points for stakeholders and postmortem
Recommended Skills
Journey fit
Incident command documentation belongs in Operate because it assumes live customer impact, SLA context, and post-stabilization closure—not greenfield build work. Errors is the canonical shelf for active SEV incidents, coordination roles, and mitigation/resolution narrative before full monitoring hardening.
How it compares
Documentation template for incident comms, not an on-call pager integration or automated status-page MCP.
Common Questions / FAQ
Who is incident-commander for?
Solo builders and tiny teams running production SaaS or APIs who must write clear incident reports without a dedicated incident management platform.
When should I use incident-commander?
In Operate when a SEV event is active or just mitigated and you need standardized impact and timeline sections before closing the incident.
Is incident-commander safe to install?
Check the Security Audits panel on this Prism page; the skill is a report scaffold and does not by itself execute infra changes—avoid pasting secrets into generated reports.
SKILL.md
READMESKILL.md - Incident Commander
# Incident Report: [INC-YYYY-NNNN] [Title] **Severity:** SEV[1-4] **Status:** [Active | Mitigated | Resolved] **Incident Commander:** [Name] **Date:** [YYYY-MM-DD] --- ## Executive Summary [2-3 sentence summary of the incident: what happened, impact scope, resolution status. Written for executive audience — no jargon, focus on business impact.] --- ## Impact Statement | Metric | Value | |--------|-------| | **Duration** | [X hours Y minutes] | | **Affected Users** | [number or percentage] | | **Failed Transactions** | [number] | | **Revenue Impact** | $[amount] | | **Data Loss** | [Yes/No — if yes, detail below] | | **SLA Impact** | [X.XX% availability for period] | | **Affected Regions** | [list regions] | | **Affected Services** | [list services] | ### Customer-Facing Impact [Describe what customers experienced: error messages, degraded functionality, complete outage. Be specific about which user journeys were affected.] --- ## Timeline | Time (UTC) | Phase | Event | |------------|-------|-------| | HH:MM | Detection | [First alert or report] | | HH:MM | Declaration | [Incident declared, channel created] | | HH:MM | Investigation | [Key investigation findings] | | HH:MM | Mitigation | [Mitigation action taken] | | HH:MM | Resolution | [Permanent fix applied] | | HH:MM | Closure | [Incident closed, monitoring confirmed stable] | ### Key Decision Points 1. **[HH:MM] [Decision]** — [Rationale and outcome] 2. **[HH:MM] [Decision]** — [Rationale and outcome] ### Timeline Gaps [Note any periods >15 minutes without logged events. These represent potential blind spots in the response.] --- ## Root Cause Analysis ### Root Cause [Clear, specific statement of the root cause. Not "human error" — describe the systemic failure.] ### Contributing Factors 1. **[Factor Category: Process/Tooling/Human/Environment]** — [Description] 2. **[Factor Category]** — [Description] 3. **[Factor Category]** — [Description] ### 5-Whys Analysis **Why did the service degrade?** → [Answer] **Why did [answer above] happen?** → [Answer] **Why did [answer above] happen?** → [Answer] **Why did [answer above] happen?** → [Answer] **Why did [answer above] happen?** → [Root systemic cause] --- ## Response Metrics | Metric | Value | Target | Status | |--------|-------|--------|--------| | **MTTD** (Mean Time to Detect) | [X min] | <5 min | [Met/Missed] | | **Time to Declare** | [X min] | <10 min | [Met/Missed] | | **Time to Mitigate** | [X min] | <60 min (SEV1) | [Met/Missed] | | **MTTR** (Mean Time to Resolve) | [X min] | <4 hr (SEV1) | [Met/Missed] | | **Postmortem Timeliness** | [X hours] | <72 hr | [Met/Missed] | --- ## Action Items | # | Priority | Action | Owner | Deadline | Type | Status | |---|----------|--------|-------|----------|------|--------| | 1 | P1 | [Action description] | [owner] | [date] | Detection | Open | | 2 | P1 | [Action description] | [owner] | [date] | Prevention | Open | | 3 | P2 | [Action description] | [owner] | [date] | Prevention | Open | | 4 | P2 | [Action description] | [owner] | [date] | Process | Open | ### Action Item Types - **Detection**: Improve ability to detect this class of issue faster - **Prevention**: Prevent this class of issue from occurring - **Mitigation**: Reduce impact when this class of issue occurs - **Process**: Improve response process and coordination --- ## Lessons Learned ### What Went Well - [Specific positive outcome from the response] - [Specific positive outcome] ### What Didn't Go Well - [Specific area for improvement] - [Specific area for improvement] ### Where We Got Lucky - [Things that could have made this worse but didn't] --- ## Communication Log | Time (UTC) | Channel | Audience | Summary | |------------|---------|----------|---------| | HH:MM | Status Page | External | [Summary of update] | | HH:MM | Slack #exec | Internal | [Summary of update] | | HH:MM | Email | Customers | [Summary of notification] | --- ## Participants | Name | Role | |-----