Incident Response Command

Writes customer-facing incident status updates for each lifecycle stage - investigating, identified, monitoring, resolved - with cadence rules and plain-language templates. Use when someone asks "write a status page update", "what do we tell customers about this outage", "draft the resolved notice", or during an active incident needing customer communication. Do NOT use for the internal post-incident analysis - use postmortem-writer once the incident is closed; for deciding severity and internal escalation flow use sev-triage; for summarizing an incident upward to executives use escalation-summary.

Drafts and sequences external communications during an incident or crisis - a first statement within the hour, acknowledge-what-you-know-without-speculating discipline, a single-spokesperson rule, channel sequencing from status page to email to social, and a legal-review escalation boundary, with severity-tiered statement templates. Use when a user says "we have an outage and customers are asking questions", "we had a data breach, what do we say publicly", "draft a public statement about this incident", "the story is blowing up on social, how do we respond", or "when do we need legal to review this statement". Do NOT use for routine technical status posts during normal-severity incidents - use status-page-update instead - for the internal writeup after resolution - use postmortem-writer instead - or for calming one angry customer - use refund-deescalation instead.

Produces a complete on-call shift handoff note - shift summary, open incidents, watch items with paging thresholds, silenced alerts, in-flight changes, and escalation contacts - checked against a completeness checklist. Use when someone asks "write my on-call handoff", "what should I tell the next on-call", "my shift ends in an hour, help me hand over", or "make a handoff template for our rotation". Do NOT use for writing the incident postmortem after resolution - use postmortem-writer instead. For live severity assessment during an incident, use sev-triage; for external customer-facing incident comms, use status-page-update.

Reduces alert noise by making alerts actionable, symptom-based, and tied to SLOs. Identifies and kills flappy, duplicate, and cause-based alerts. Use when alert fatigue is degrading on-call response quality.

Defines and applies an SLO error-budget policy that gates feature work versus reliability work based on remaining budget. Use when setting up SLOs or when high burn rate lacks a formal team response protocol.

Instruments systems with the three pillars - structured logs, RED/USE metrics, and distributed traces - correlated by one trace ID, with cardinality budgets and symptom-based alerts. Use when someone asks "how should I instrument this service", "what metrics should I emit", "why is my metrics bill exploding", "set up OpenTelemetry for my stack", or "we can't tell which service is slow". Do NOT use for tuning an existing noisy pager or alert thresholds - use alert-tuning instead; for defining SLO error-budget policy, use error-budget-policy; for the incident process when alerts fire, use sev-triage and postmortem-writer.

Writes blameless incident postmortems with a log-reconstructed timeline, multi-causal contributing factors, and owned, dated action items. Use when someone asks "write the postmortem for yesterday's outage", "run a blameless retro on this incident", "turn these incident notes into a postmortem doc", or after any SEV1 or SEV2 event. Do NOT use for customer-facing incident updates while the incident is live - use status-page-update instead; for transferring context at a shift change, use oncall-handoff; for classifying and running a live incident, use sev-triage.