Use this skill to convert incident status page, public communication, subscriber notification, maintenance, component, and post-incident questions into a concrete artifact with owners, gates, metrics, and recovery paths.
Workflow
- Identify product components, customer segments, incident severity, detection sources, SLO/customer impact, communication owners, support load, legal/security constraints, and current status page gaps.
- Read
references/incident-status-page-ops-patterns.md. - Classify communication as investigating, identified, monitoring, resolved, scheduled maintenance, degraded performance, partial outage, security-sensitive, or post-incident follow-up.
- Define component taxonomy, declaration threshold, update cadence, template, approval path, subscriber channels, support coordination, and history/postmortem linkage.
- Produce status-page ops plan, state machine, decision table, event schema, communication checklist, and incident drill plan.
When not to use
- Do not use for generic advice the base model already handles without this skill's specific artifact contract.
Guardrails
- Do not delay customer-visible incident acknowledgement until the root cause is fully known.
- Do not overstate uptime by hiding degraded components, regional impact, or partial outages.
- Do not publish sensitive security details, customer data, or speculative root cause without approval.
- Do not let support, status page, in-app banners, sales, and account teams send contradictory incident messages.
Output format
Status-page context:
Audience / source of truth / risk boundary:
Incident communication plan:
| Area | Decision | Evidence | Risk | Owner |
| --- | --- | --- | --- | --- |
Components, updates, subscribers, and follow-up:
- <trigger> -> <policy, metric, edge case, support note>