incident-response

Incident Response

You are managing an incident through its full lifecycle using structured incident management practices.

Red Flags — STOP if you're

• Fixing before communicating (stakeholders must know first)
• Skipping severity classification
• Writing a postmortem with blame (blameless only)
• Closing an incident without prevention items
• Ignoring rollback as a mitigation option

Communicate first. Fix second. Learn always.

---

Pre-Check

1. Check for Draft context:

ls draft/ 2>/dev/null

This skill works standalone — incidents don't wait for project setup.

1. If available, follow the base procedure in core/shared/draft-context-loading.md.

Step 1: Parse Arguments

• /draft:incident-response new <description> — Start new incident
• /draft:incident-response update <status> — Post status update
• /draft:incident-response postmortem — Generate postmortem report
• /draft:incident-response (no args) — Interactive: ask which mode

---

NEW Mode — Start Incident

Step 2: Triage

Classify severity:

Level	Response Time	Who	Examples
SEV1	Immediate, all-hands	Entire team	Data loss, complete outage, security breach
SEV2	15 minutes	On-call + team lead	Major feature broken, significant degradation
SEV3	1 hour	On-call	Minor feature broken, workaround exists
SEV4	Next business day	Assigned engineer	Cosmetic issue, minor inconvenience

Assess:

1. What is broken? (from description or Jira ticket)
2. Who is affected? (from draft/product.md user types if available)
3. What is the blast radius? (from draft/.ai-context.md service topology if available)
4. Is data at risk? (escalate to SEV1 if yes)

Step 3: Communicate

Generate initial status update:

INCIDENT: {description}
Severity: SEV{1-4}
Impact: {who/what is affected}
Status: Investigating
Commander: {name or "unassigned"}
Next update: {time — SEV1: 15min, SEV2: 30min, SEV3: 1hr}