Draft audience-segmented updates during a live incident — customer status-page posts, internal stakeholder updates, and exec notifications — each leading with user-facing impact, never speculative cause or ETA, always naming the next-update time. Use when an incident is in progress and the user needs a status page post, customer notification, internal update, exec brief, or the resolved/all-clear message.
Pack sre-oncallTier standardJob Run and recover the servicev0.1.0
In Claude Code, with the sre-oncall plugin installed, invoke it as:
/sre-oncall:incident-comms
Try it
A realistic prompt from the skill's acceptance evals:
We're 20 minutes into a live incident — checkout is failing for about 30% of users, cause not yet confirmed. Draft the customer, internal, and exec updates.
What a good result looks like
First sentence is reader-facing impact, not internal symptom. If a customer needs your architecture diagram to parse it, rewrite.
Every message names the next-update time (or marks it [set HH:MM]). The cadence promise is the entire contract; an update with no next-time is a dead end.
Zero retractable claims. No unconfirmed cause, no committed fix-ETA, no premature all-clear. The only time committed is the next update.
Three audiences are genuinely different, not one text with words swapped. Exec version is business impact + ask; customer version is impact + action; internal version arms the relayer.
Blameless and forward-safe — no person, no unconfirmed vendor blame, nothing you wouldn't want screenshotted.
Resolve messages tell still-affected users what to do and promise the postmortem for SEV1/2.
How it's checked
Measured against plain Claude Code (2026-10-23): it met 77% of its checks, against 65% without it, and a blind judge had no preference. How skills are checked
18 assertions across 3 acceptance evals, and 8 trigger queries. Every skill's checks
What the output must do
Each message's first sentence is reader-facing impact, not an internal symptom or architecture detail
Every message names the next-update time, or marks it [set HH:MM] when unknown
No unconfirmed cause is stated and no commitment is made that might need retracting
The three audiences (customer status page, internal stakeholders, exec) get genuinely different messages rather than one text reused
Nothing is asserted beyond what the operator supplied
The customer post describes the impact accurately: card payments at ticket machines failing, app top-ups partly failing, cash at machines working, and does not say all top-ups are down or that the problem is fixed
No customer-facing message gives the database failover theory or the '30 minutes' estimate, and the CEO note says there is no ETA yet instead of inventing one
Tells riders that inspectors will accept people who could not top up, until the end of service today
Describes the 'charged twice' reports as temporary holds that should drop off within 3 to 5 working days, without promising refunds or saying riders were charged twice
Each message states when the next update will come, and no public message names the payment processor or uses the word 'breach'
The status page post is no more than 600 characters
Does not invent figures, times, causes or actions that are not in the channel log
Delivers both a text message and an email ready to send, without stopping to ask questions first
The text message is 160 characters or fewer
Both say children will still get lunch today and parents can pay later
Neither gives a cause or promises when the system will be fixed
Tells parents when or how the school will update them next
Does not invent details that were not given, such as a payment deadline, refunds, a supplier name or a fix time
When it should and shouldn't activate
Should activate:
Draft a status page update for this ongoing incident
We're live in an incident — I need customer, internal, and exec updates
Write the customer-facing comms while we investigate
How do I tell stakeholders about this outage right now?
Should leave to another skill:
Write the blameless postmortem now that it's resolved
Generate the runbook for this service
Summarize this technical doc for executives
Extract decisions and action items from the incident channel
Hands off to
postmortem-generator — when the incident is resolved. Analyse blamelessly and emit runbook deltas.