Status Page Context

Status Page Context

Create and maintain .agents/status-page-context.md — the foundational context document referenced by all other status page skills.

When to Use

• First time using any status page skill
• "set up my status page context"
• "configure my incident communication style"
• "update my SLA commitments"
• User wants to define components, tone, or escalation paths

Workflow

1. Check for Existing Context

Look for .agents/status-page-context.md in the project root.

• If it exists: Read it and ask the user what they want to update.
• If it doesn't exist: Offer two modes:
  • Auto-draft: Scan the codebase for clues (README, config files, status page config, package.json) and pre-fill what you can.
  • Start from scratch: Walk through each section interactively.

2. Gather Context

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.

3. Write the File

Write the completed context to .agents/status-page-context.md. Use the template below.

Context Template

# 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:**
-

Guidelines

• Be specific. "Conversational but professional" is better than "friendly."
• Include real examples. A sample sentence in the right tone is worth more than a paragraph describing the tone.
• Components matter. Downstream skills use the component list to scope incident updates and maintenance announcements.
• Severity levels drive behavior. The incident-communication skill uses these to calibrate urgency and update frequency.
• Keep it current. Re-run this skill when you add components, change SLAs, or shift communication style.

Related Skills

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