Incident Status Comms

When your service is broken, your customers need honest, timely, plain-language communication — not internal war-room chatter. This skill is a playbook for writing customer-facing incident notices: the initial alert, mid-incident updates, and the resolution message. It does not decide what to do about the incident; it tells you exactly what to say about it.

Turn verified facts about an outage, degradation, or bug into clear customer-facing status updates that reduce support load, preserve trust, and avoid the two classic failure modes of incident comms: going silent, or speculating about things you don't know yet. This skill covers COMMUNICATION ONLY. Incident triage, root-cause analysis, and response decisions belong to your incident response workflow (for example, a sev-decision playbook handles decision-making; this skill handles what customers hear).

• Your service, product, or feature is degraded or down and customers may notice.

• You need to write a status-page post, in-app banner, or email notice about an incident.

• Stakeholders keep asking "what do we tell customers?" during an active incident.

• You need to draft the public resolution message after service is restored.

• You want to announce a postmortem or follow-up action publicly without admitting liability.

• For internal war-room decisions: severity calls, escalation, root-cause analysis, rollback vs. hotfix tradeoffs. This skill assumes those decisions are already being made elsewhere.

• As an incident detector. This skill drafts messages; it cannot tell you an incident is happening, monitor uptime, or verify system state. Only use facts verified by your monitoring or engineering team.

• For legal or regulatory breach-notification obligations (e.g., data-breach disclosure). Those have legal requirements this playbook does not cover; involve legal counsel.

• For marketing the postmortem. The postmortem teaser here is a trust-building follow-up, not content marketing.