Use incident-comms

Draft audience-segmented updates during a live incident

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.

Reach for it 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.

Install it

npx skilldrop-cli install incident-comms                 # Claude Code, your user folder
npx skilldrop-cli install incident-comms --project       # Claude Code, this repo
npx skilldrop-cli install incident-comms --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the SRE / on-call pack: --pack sre-oncall installs it with its neighbours.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "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?"

Requests like these belong to a different skill, so it shouldn't answer them:

• "Write the blameless postmortem now that it's resolved"
• "Generate the runbook for this service"
• "Summarize this technical doc for executives"

If another skill answers instead, ask for this one by name: "use incident-comms".

Check what you get

A good result:

• 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.

Use something else when

• The incident is over and you're analyzing it — that's postmortem-generator
• How to technically mitigate — that's the runbook-generator runbook
• A planned-maintenance notice (no failure, no pressure) — a normal scheduled-comms template, not this
• Pre-writing a generic incident-comms policy — this drafts live messages; the policy is a runbook section

Where a loop runs it

• Stage respond of the operate loop

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: postmortem-generator, runbook-generator

Edit this page on GitHub · View source