---
name: outage-comms-writer
description: Drafts internal, customer, and status-page messages during a live incident, tone-matched to severity and kept factual under pressure.
version: 1.0.0
author: VantagePoint Networks
audience: IT Managers, Incident Commanders, Comms Leads, Service Desk Managers
output_format: Formatted Markdown with three parallel drafts (internal / customer / status page) plus a comms cadence schedule.
license: MIT
---

# Outage Comms Writer

A live-incident sidekick that produces three synchronised messages - internal, customer-facing, status-page - tuned to severity and ready to paste in 60 seconds.

## How to use this skill

1. Download this `SKILL.md` file.
2. Place it in `~/.claude/commands/` (macOS/Linux) or `%USERPROFILE%\.claude\commands\` (Windows).
3. Run `/outage-comms-writer` in Claude Code mid-incident. Give it the current state (what you know, what you don't). It produces three drafts and a cadence for the next updates.
4. As the situation changes, rerun with the new state - drafts follow the same format so stakeholders recognise the rhythm.

## When to use this

- You're running a live incident and the first customer update needs to go out in the next 5 minutes.
- Leadership is demanding an internal update and you don't want to dump incident jargon on them.
- You want a clean status page message and a longer customer email that say the same thing in different registers.
- You're a comms lead shadowing an incident and need to separate your role from the technical response.
- You're documenting the comms trail after the fact and want a consistent reconstruction.

## What you'll get

- **Internal update** for staff / Slack / Teams - more technical detail, acknowledges known unknowns, sets next checkpoint time.
- **Customer-facing update** for email / banner / in-app - plain English, no internal names, apology + facts + next update time.
- **Status page update** - short, structured, follows status page conventions (Investigating / Identified / Monitoring / Resolved).
- **Executive / exec-sponsor briefing** - 4-5 lines for the CTO or CEO if severity warrants.
- **Comms cadence plan** - when to send the next update, to whom, in which format.
- **"Known knowns / known unknowns / don't-say-this-yet" matrix** - stops you from over-promising mid-incident.

## Clarifying questions I will ask you

1. **What is the incident severity?** (P1 customer-visible / P2 partial / P3 internal-only / P4 minor)
2. **What service or product is affected, in a customer-facing name (not the internal system name)?**
3. **What can customers actually do / not do right now?** (Log in? Checkout? Download? View dashboard?)
4. **When did it start, and when was it detected?** (Two separate times if known.)
5. **What do you know about the cause with high confidence?**
6. **What do you suspect but not confirm?** (Will NOT be published yet.)
7. **What have you done to fix it, and what is in progress now?**
8. **Is there a workaround customers can use right now?**
9. **What audiences need to hear from us?** (All staff, all customers, enterprise customers only, a specific partner, a regulator)
10. **When will you realistically have the next substantive update?** (Drives the cadence.)
11. **Has anything been promised to anyone already?** (Don't contradict.)
12. **Tone register you want?** (Matter-of-fact / apologetic / technical / reassuring)

## Output template

```markdown
# Outage Comms - <service name> - update <N> - YYYY-MM-DD HH:MM UTC

## Incident snapshot (internal only, not published)
| Field | Value |
|---|---|
| Severity | P<N> |
| Customer-facing name | <e.g. "Portal login"> |
| Internal system | <e.g. "authz-gateway"> |
| Start | YYYY-MM-DD HH:MM UTC |
| Detected | YYYY-MM-DD HH:MM UTC |
| Current status | Investigating / Identified / Monitoring / Resolved |
| Incident commander | <name> |
| Next update due | HH:MM UTC (in <N> minutes) |

## What we know / suspect / must not say yet
| Bucket | Content |
|---|---|
| Known knowns (safe to publish) | <facts with evidence> |
| Known unknowns (acknowledge publicly) | <gaps> |
| Suspected (internal only, do NOT publish) | <hypotheses> |

---

## Draft 1 - Internal (Slack / Teams #incidents channel)
**Audience:** all staff who might see customer questions.
**Tone:** colleague-to-colleague, direct, technical OK.

> :rotating_light: **P<N> incident - <service>** - update <N>
>
> **Status:** <Investigating / Identified / Monitoring / Resolved>
> **What's broken:** <short, plain>
> **Impact:** <who is affected, doing what>
> **Cause:** <if identified, else "under investigation">
> **What we're doing:** <current workstreams + owners>
> **Customer-facing messaging:** <where it is, who's seen it>
> **Next update:** <HH:MM UTC / as soon as status changes>
> **Bridge:** <link / number>
> **IC:** <name>

---

## Draft 2 - Customer-facing (email / in-app banner / help-desk reply)
**Audience:** affected customers.
**Tone:** plain English, apologetic, factual, actionable.

> **Subject:** <Service> - service disruption update
>
> Hello,
>
> We are currently experiencing an issue with <service> that started at <start time and timezone>. <What customers cannot do>. <Workaround if any, else "We apologise for the inconvenience.">
>
> Our team identified the issue at <detection time> and is actively working on a resolution. <Optional: one-sentence cause in plain English if confirmed.> We will send another update by <next update time>.
>
> For real-time status, see our status page: <URL>.
>
> We're sorry for the disruption.
>
> <Signing team / company>

---

## Draft 3 - Status page (structured per status page conventions)
**Audience:** anyone watching the status page.
**Tone:** telegraphic, factual.

> **[<Service name>]** <one-line symptom>
>
> **Status:** Investigating / Identified / Monitoring / Resolved
> **Started:** <UTC time>
> **Impact:** <component + scope>
>
> <2-3 sentences, updated each status transition. Never speculate publicly.>
>
> Next update: <UTC time>.

---

## Draft 4 - Executive briefing (only for P1/P2)
**Audience:** CTO / CEO / exec sponsor.
**Tone:** crisp, decision-oriented.

> Summary: <one sentence>
> Customer impact: <who, doing what, for how long>
> Revenue risk: <estimate or "under review">
> Status right now: <investigating/identified/monitoring/resolved>
> Action needed from you: <none / sign-off on customer statement / escalate to partner X>

## Comms cadence plan (next 4 hours)
Adjust based on severity. P1 = tighter cadence.

| Time | Audience | Channel | Owner | Condition |
|---|---|---|---|---|
| +15 min | Customers | Status page | Comms Lead | Even if "no change", acknowledge we're on it |
| +30 min | Internal | Slack #incidents | IC | Update on investigation |
| +60 min | Customers | Email (if P1/P2) | Comms Lead | Substantive update |
| +90 min | Internal | Slack #incidents | IC | Update on investigation |
| +120 min | Customers | Status page | Comms Lead | Substantive update or "still investigating, ETA X" |
| On resolution | All | All channels | IC + Comms Lead | Simultaneous |
| +24h | Customers | Email | Comms Lead | Incident summary |

## Do NOT:
- Speculate publicly on cause before it's confirmed
- Give an ETA you're not 90% sure about (under-promise / over-deliver)
- Name a vendor / third party as the cause unless their public statement agrees
- Use internal jargon or system names in customer messages
- Apologise for things that weren't your fault without legal review (enterprise contracts)
- Go silent for more than the cadence interval - even "no news" is news mid-incident
```

## Example invocation

**User:** "/outage-comms-writer - P2, portal login is broken for about 30% of customers since 09:42 UTC, detected at 09:48, we think it's our SSO provider but not confirmed. Engineering is on a bridge. I need a customer-facing update in 2 minutes."

**What the skill will do:**
1. Generate all three drafts with careful separation: internally you can say "appears to be SSO provider issue, awaiting their confirmation" - publicly you say "authentication issue, working to resolve" without pointing at the vendor.
2. Propose a 15-minute cadence while "identified but not fixed" state holds.
3. Flag in the "must not say" box that you haven't confirmed the vendor is the cause - if their status page disagrees when you publish, you look bad.
4. Include a workaround line if you've verified one (e.g. "users who are already logged in are unaffected").

## Notes for the requester

- **Update cadence promises create expectations.** "Next update in 30 minutes" is a promise. Keep it, even if the update is "still investigating, ETA to identify cause: 45 minutes."
- **Internal jargon is confusing to customers.** "authz-gateway" means nothing. "Sign-in" does. The skill will translate but double-check.
- **Resolve the status page before sending the all-clear email.** Customers will check the status page on seeing the email - an inconsistent state destroys trust.
- **Save the drafts.** After the incident, the comms trail is a critical input to the post-mortem and any customer escalations.
- **"Good" looks like:** a customer who knows only what your messages told them understands the state and does not feel ignored. Internal staff answering tickets give consistent answers. Leadership hears before Twitter does.