Individual skill

status-page-update

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.

skills/status-page-update/SKILL.md

Read pinned source

Source commit 97a13607d669157a4a16d5ba79b77f208319f7b9

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
No
Repository scan complete
No
Skill scan complete
Yes
Observed behavior
Not checked yet
Last checked
Nov 6, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
24
Repository last updated
Oct 13, 2026
License
MIT

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt

# Status Page Update

Customers do not need the stack trace. They need to know what is broken, whether the team knows about it, and when it will be fixed. Every update earns trust or burns it - and the two fastest ways to burn it are silence (no post while customers are clearly affected) and a premature "resolved" that gets reopened. This skill produces updates that are fast, honest, specific about scope, and never blame anyone.

## Inputs to collect

Before writing any update, get:

1. **The observable symptom** - what customers actually experience, in their terms ("API requests returning 500s"), not internal terms ("the ingest shard is degraded").
2. **The affected scope** - which customers, which region, which feature. "Customers using API key authentication in us-east-1," never "some customers."
3. **The stage** - investigating, identified, monitoring, or resolved. The stage dictates the template and what may be promised.
4. **Timestamps** - incident start, and the timezone convention (UTC with label, or the user's timezone).
5. **The cause in plain language** - only for identified and later; never speculate before then.
Back to top