// Create or update the status page context document that all other status page skills reference. Use when setting up status page skills for the first time, or when the user mentions "status page context," "configure status page," "set up incident tone," or wants to define their service components, SLAs, or communication style.
Design, scaffold, and contribute a community theme to openstatus (the open-source status page). Use whenever the user wants to create a new theme, customize status-page colors, build a palette for their brand, fork and contribute to openstatus's `@openstatus/theme-store`, or mentions OKLCH colors, CSS variables, or themes.openstatus.dev. Also use when the user pastes a theme export from the live explorer and wants it wired into the repo.
Build a custom status page UI using OpenStatus components or SDK. Use when someone wants to "create a status page," "build a status page," "integrate OpenStatus UI," "embed a status widget," "add status page components," or render monitors, incidents, and maintenance in their own app.
Write clear, empathetic incident status updates for any phase of an incident (investigating, identified, monitoring, resolved). Use when the user mentions "incident update," "status update," "outage communication," "write an incident," "investigating update," "post-incident update," or needs to communicate a service disruption to users.
Write planned maintenance announcements for each phase (scheduled, in-progress, completed). Use when the user mentions "maintenance announcement," "scheduled maintenance," "maintenance window," "planned downtime," "maintenance notification," or needs to communicate upcoming planned work to users.
Write blameless postmortems after incidents with timeline, root cause analysis, impact assessment, and action items. Use when the user mentions "postmortem," "post-mortem," "incident review," "root cause analysis," "RCA," "incident retrospective," "what went wrong," or wants to document lessons from a resolved incident.
Write periodic status reports summarizing overall system health, uptime, incidents, and maintenance. Use when the user mentions "status report," "health report," "uptime report," "weekly status," "monthly report," "system health summary," "reliability report," or wants to publish a regular update on how their services are performing.
| name | status-page-context |
| version | 0.1.0 |
| description | Create or update the status page context document that all other status page skills reference. Use when setting up status page skills for the first time, or when the user mentions "status page context," "configure status page," "set up incident tone," or wants to define their service components, SLAs, or communication style. |
Create and maintain .agents/status-page-context.md — the foundational context document referenced by all other status page skills.
Look for .agents/status-page-context.md in the project root.
For each section below, ask the user to fill in or confirm. Pre-fill from codebase where possible. Do NOT skip sections — each one is used by downstream skills.
Write the completed context to .agents/status-page-context.md. Use the template below.
# Status Page Context
*Last updated: [date]*
## Service Overview
**Company/Product name:**
**One-liner:**
**Status page URL:**
**Primary audience:** (e.g., developers, enterprise customers, end users)
## Components
List every component shown on your status page.
| Component | Description | Criticality |
|-----------|-------------|-------------|
| | | High / Medium / Low |
## SLA & Uptime Commitments
**Uptime target:** (e.g., 99.9%, 99.95%)
**Response time SLA:** (e.g., acknowledge within 15 min, update every 30 min)
**Maintenance window:** (e.g., Tuesdays 2-4am UTC)
**SLA consequences:** (e.g., credits, contractual obligations)
## Communication Tone
**Style:** (formal / conversational / technical)
**Voice characteristics:** (e.g., calm, transparent, empathetic, no corporate jargon)
**Words to use:**
-
**Words to avoid:**
-
**Example good sentence:**
> "[example that sounds like your brand]"
## Severity Levels
| Level | Criteria | Example |
|-------|----------|---------|
| Critical | Complete service outage or data loss | API returning 500 for all requests |
| Major | Significant degradation affecting most users | Dashboard load times >10s |
| Minor | Limited impact, workaround available | Webhook delays of 2-5 minutes |
| Maintenance | Planned work, no unexpected impact | Scheduled database migration |
## Escalation & Roles
**Incident commander:** (role or person responsible for coordinating response)
**Communications lead:** (who writes/approves status updates)
**Update cadence:** (how often to post updates during an incident)
**Approval required:** (yes/no — do updates need sign-off before publishing?)
## Notification Channels
Where do status updates get published?
- [ ] Status page
- [ ] Email subscribers
- [ ] Slack/Discord
- [ ] Twitter/X
- [ ] In-app banner
- [ ] Other:
## Past Patterns
**Common incident types:**
-
**Recurring root causes:**
-
**Lessons from past incidents:**
-
incident-communication skill uses these to calibrate urgency and update frequency.incident-communication — Write incident updates (uses this context for tone and components)postmortem — Write blameless postmortems (uses this context for severity and past patterns)maintenance — Write maintenance announcements (uses this context for components and maintenance windows)status-report — Write periodic health reports (uses this context for components and SLA targets)