{"id":"5f89f3f9-a167-4dee-920b-02a01331a049","entityType":"agent","slug":"clawhub-openstatus-incident-communication-playbook","name":"Status page & incident communication by openstatus","canonicalUrl":"https://www.xpersona.co/agent/clawhub-openstatus-incident-communication-playbook","canonicalPath":"/agent/clawhub-openstatus-incident-communication-playbook","generatedAt":"2026-10-11T08:43:15.594Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T06:12:45.655Z","emptyReason":null},"description":"Write professional incident updates, blameless postmortems, maintenance announcements, and status reports for your status page. Includes real-world examples...","descriptionLabel":"Source description","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.1K downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s17ba5jfpwvh6xdbv0hcyz0qpn84y0ed:incident-communication-playbook","sourceUrl":"https://clawhub.ai/openstatus/incident-communication-playbook","homepage":"https://clawhub.ai/openstatus/skills/incident-communication-playbook","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/openstatus/incident-communication-playbook","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/openstatus/skills/incident-communication-playbook","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":61,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Status page & incident communication by openstatus technical dossier on Xpersona with agent coverage, OPENCLEW support, and live trust metadata."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T06:12:45.655Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T06:12:45.655Z","emptyReason":null},"stars":null,"forks":null,"downloads":1137,"packageName":null,"latestVersion":"1.0.0","tractionLabel":"1.1K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T06:12:45.586Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T06:12:45.655Z","lastCrawledAt":"2026-10-11T06:12:45.586Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T06:12:45.586Z","lastVerifiedAt":null,"highlights":[{"version":"1.0.0","createdAt":"2026-04-16T09:10:43.804Z","changelog":"Initial release of incident-communication skill. - Enables writing professional incident updates for any incident phase: investigating, identified, monitoring, resolved. - Integrates real-world communication examples from Vercel, Stripe, GitHub, and Cloudflare. - Automatically uses your status page’s tone, components, and SLAs by referencing status-page-context. - Bundled with templates, principles, anti-patterns, and quality checklists to ensure effective updates. - Designed for on-call engineers, SREs, DevOps, engineering managers, and anyone responsible for status page communication.","fileCount":24,"zipByteSize":55925}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17ba5jfpwvh6xdbv0hcyz0qpn84y0ed:incident-communication-playbook","setupComplexity":"low","setupSteps":["Install using `clawhub skill install s17ba5jfpwvh6xdbv0hcyz0qpn84y0ed:incident-communication-playbook` in an isolated environment before connecting it to live workloads.","No published capability contract is available yet, so validate auth and request/response behavior manually.","Review the upstream CLAWHUB listing at https://clawhub.ai/openstatus/incident-communication-playbook before using production credentials."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-openstatus-incident-communication-playbook/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-openstatus-incident-communication-playbook/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-openstatus-incident-communication-playbook/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-openstatus-incident-communication-playbook/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-openstatus-incident-communication-playbook/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-openstatus-incident-communication-playbook/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-11T08:43:15.592Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-openstatus-incident-communication-playbook/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-openstatus-incident-communication-playbook/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-openstatus-incident-communication-playbook/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-openstatus-incident-communication-playbook/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T06:12:45.655Z","emptyReason":null},"readme":"Skill: Status page & incident communication by openstatus\n\nOwner: openstatus\n\nSummary: Write professional incident updates, blameless postmortems, maintenance announcements, and status reports for your status page. Includes real-world examples...\n\nTags: latest:1.0.0\n\nVersion history:\n\nv1.0.0 | 2026-04-16T09:10:43.804Z | user\n\nInitial release of incident-communication skill.\n\n- Enables writing professional incident updates for any incident phase: investigating, identified, monitoring, resolved.\n- Integrates real-world communication examples from Vercel, Stripe, GitHub, and Cloudflare.\n- Automatically uses your status page’s tone, components, and SLAs by referencing status-page-context.\n- Bundled with templates, principles, anti-patterns, and quality checklists to ensure effective updates.\n- Designed for on-call engineers, SREs, DevOps, engineering managers, and anyone responsible for status page communication.\n\nArchive index:\n\nArchive v1.0.0: 24 files, 55925 bytes\n\nFiles: README.md (3080b), skill-card.md (2636b), skills.md (3126b), skills/incident-communication/evals/evals.json (5299b), skills/incident-communication/references/examples.md (6601b), skills/incident-communication/references/framework.md (4249b), skills/incident-communication/SKILL.md (7076b), skills/maintenance/evals/evals.json (5379b), skills/maintenance/references/examples.md (6891b), skills/maintenance/references/framework.md (4715b), skills/maintenance/SKILL.md (8589b), skills/postmortem/evals/evals.json (5676b), skills/postmortem/references/examples.md (7277b), skills/postmortem/references/framework.md (5979b), skills/postmortem/SKILL.md (8578b), skills/status-page-context/evals/evals.json (3835b), skills/status-page-context/references/examples.md (3313b), skills/status-page-context/references/framework.md (2993b), skills/status-page-context/SKILL.md (4475b), skills/status-report/evals/evals.json (5201b), skills/status-report/references/examples.md (5741b), skills/status-report/references/framework.md (5755b), skills/status-report/SKILL.md (9480b), _meta.json (150b)\n\nFile v1.0.0:skills/incident-communication/SKILL.md\n\n---\nname: incident-communication\nversion: 0.1.0\ndescription: 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.\n---\n\n# Incident Communication\n\nWrite status page updates that are clear, honest, and useful — for any phase of an incident.\n\n## When to Use\n\n- \"write an incident update\"\n- \"we have an API outage, help me communicate it\"\n- \"draft a resolved update for the database incident\"\n- \"our webhooks are delayed, what should I post?\"\n\n## Workflow\n\n### 1. Check for Context\n\nRead `.agents/status-page-context.md` if it exists. Use it for:\n- **Tone and voice** — match the team's communication style\n- **Components** — reference the correct component names\n- **Severity levels** — calibrate urgency appropriately\n- **Update cadence** — respect the team's SLA for update frequency\n\nIf the file doesn't exist, suggest running the `status-page-context` skill first. Proceed without it if the user wants to skip.\n\n### 2. Determine the Phase\n\nAsk the user which phase they're in if not obvious from their message:\n\n| Phase | When | Purpose |\n|-------|------|---------|\n| **Investigating** | Something is wrong, cause unknown | Acknowledge the issue, set expectations |\n| **Identified** | Root cause found, fix in progress | Explain what's happening, share the plan |\n| **Monitoring** | Fix deployed, watching for stability | Confirm the fix, set recovery expectations |\n| **Resolved** | Incident is over | Summarize what happened with exact timeframes |\n\n### 3. Gather Incident Details\n\nFor any phase, you need:\n- **What's affected** — which components/services (use names from context if available)\n- **What's the user impact** — what are users experiencing? (errors, slowness, data loss)\n- **What's NOT affected** — critical for reducing panic\n- **What's being done** — current actions being taken\n\nAdditional details by phase:\n- **Investigating:** When did it start? Who reported it?\n- **Identified:** What's the root cause? What's the fix plan? ETA?\n- **Monitoring:** What fix was deployed? How long will monitoring last?\n- **Resolved:** Exact start/end times (UTC). What was the root cause? Will there be a postmortem?\n\n### 4. Write the Update\n\nFollow these principles (in priority order):\n\n#### Principle 1: Scope the blast radius immediately\nThe first sentence should tell users what's affected AND what's not.\n\n**Do:** \"REST API requests are returning elevated 5xx errors. The dashboard and webhook delivery are operating normally.\"\n**Don't:** \"We are investigating reports of degraded performance for some services.\"\n\n#### Principle 2: Be specific about user impact\nDescribe what users are experiencing, not just what's broken internally.\n\n**Do:** \"Deployments created between 11:20 and 15:14 UTC may be failing. Existing deployments are unaffected.\"\n**Don't:** \"We are experiencing an issue with our deployment pipeline.\"\n\n#### Principle 3: Give actionable guidance when possible\nIf users can do something to mitigate, tell them.\n\n**Do:** \"If you're seeing errors, redeploying will resolve the issue for your project.\"\n**Don't:** \"We are working on a fix.\"\n\n#### Principle 4: Include timestamps in UTC\nEvery update should reference when things happened.\n\n**Do:** \"Starting at 14:25 UTC, iDEAL transactions began failing.\"\n**Don't:** \"We recently noticed some issues.\"\n\n#### Principle 5: Set expectations for the next update\nTell users when they'll hear from you again.\n\n**Do:** \"We'll post another update within 30 minutes or sooner if the situation changes.\"\n**Don't:** (silence)\n\n#### Principle 6: Resolved updates summarize the full story\nInclude exact time window, what happened, what was done, and whether a postmortem will follow.\n\n**Do:** \"Between 18:00 and 18:23 UTC, the REST API experienced elevated error rates (peak 12% of requests) caused by a misconfigured load balancer rule. The rule was rolled back at 18:19 UTC and error rates returned to normal by 18:23 UTC. We'll publish a full postmortem within 48 hours.\"\n**Don't:** \"This incident has been resolved.\"\n\n### 5. What to Communicate Next\n\nAfter writing the update, always tell the user what comes next:\n- **After investigating:** \"When you identify the cause, run this skill again for an 'identified' update.\"\n- **After identified:** \"Once the fix is deployed, run this skill for a 'monitoring' update.\"\n- **After monitoring:** \"When you're confident the fix is stable, run this skill for a 'resolved' update.\"\n- **After resolved:** \"Consider writing a postmortem — use the `postmortem` skill.\"\n\n## Phase Templates\n\n### Investigating\n\n```\n[Component] is experiencing [user-visible impact] starting at [time UTC].\n[What is NOT affected].\nWe are investigating the cause and will provide an update by [time/timeframe].\n```\n\n### Identified\n\n```\nWe've identified the cause of [brief description of issue affecting Component].\n[Root cause in plain language].\nWe are [action being taken] and expect [recovery ETA or \"will update when we have an ETA\"].\n[What users can do in the meantime, if anything].\nNext update by [time/timeframe].\n```\n\n### Monitoring\n\n```\nA fix for [brief issue description] has been deployed at [time UTC].\n[What the fix was, in one sentence].\nWe are monitoring for stability and will resolve this incident if no further issues arise within [timeframe].\n[Any user action needed, e.g., \"no action needed\" or \"you may need to retry failed requests\"].\n```\n\n### Resolved\n\n```\nBetween [start time] and [end time] UTC, [Component] experienced [user-visible impact].\n[Root cause in 1-2 sentences].\n[What was done to fix it].\n[Impact summary: % of users/requests affected, if known].\n[Postmortem commitment: \"We'll publish a detailed postmortem within [timeframe]\" or \"No further action needed\"].\n```\n\n## Anti-patterns to Avoid\n\n| Anti-pattern | Why it's bad | Instead |\n|--------------|-------------|---------|\n| \"We apologize for any inconvenience\" | Empty corporate filler | State impact honestly and what you're doing |\n| \"Some users may experience issues\" | Vague, unhelpful | Specify what users see and who's affected |\n| \"We are continuing to investigate\" (repeated) | No new information | Share what you've learned, even if partial |\n| \"This incident has been resolved\" (with no details) | Users don't know what happened | Summarize timeline, cause, fix, and impact |\n| \"Please be patient\" | Patronizing | Give an ETA or next update time |\n| Copy-pasting the same update multiple times | Looks lazy, erodes trust | Each update should add new information |\n\n## Related Skills\n\n- `status-page-context` — Set up the context document this skill reads (tone, components, severity)\n- `postmortem` — Write a detailed postmortem after a resolved incident\n- `maintenance` — Write planned maintenance announcements (not incidents)\n- `status-report` — Write periodic health reports\n\nFile v1.0.0:skills/maintenance/SKILL.md\n\n---\nname: maintenance\nversion: 0.1.0\ndescription: 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.\n---\n\n# Maintenance\n\nWrite maintenance announcements that give users everything they need to prepare, stay informed, and confirm completion.\n\n## When to Use\n\n- \"write a maintenance announcement\"\n- \"we have database maintenance next Tuesday\"\n- \"draft a maintenance-in-progress update\"\n- \"announce that the maintenance is done\"\n\n## Workflow\n\n### 1. Check for Context\n\nRead `.agents/status-page-context.md` if it exists. Use it for:\n- **Component names** — reference the correct service names\n- **Maintenance window** — default schedule if one is defined\n- **Tone** — match the team's communication style\n- **Notification channels** — remind about where to publish\n\nIf the file doesn't exist, suggest running the `status-page-context` skill first. Proceed without it if the user wants to skip.\n\n### 2. Determine the Phase\n\nAsk the user which phase if not obvious:\n\n| Phase | When | Purpose |\n|-------|------|---------|\n| **Scheduled** | Before the maintenance | Give users time to prepare |\n| **In-progress** | Maintenance has started | Confirm it's happening, set expectations |\n| **Completed** | Maintenance is done | Confirm everything is back to normal |\n| **Cancelled** | Maintenance won't happen | Inform users the planned work is called off |\n| **Extended** | Maintenance is running longer than planned | Update the expected end time |\n\n### 3. Gather Details\n\n**For scheduled announcements:**\n- What components/services are affected?\n- What is the maintenance window? (start time, end time, timezone — always convert to UTC)\n- What will users experience? (full downtime, degraded performance, intermittent errors)\n- What should users do to prepare? (save work, expect delays, switch regions)\n- How far in advance is this being announced?\n- Is there a workaround during the maintenance?\n\n**For in-progress updates:**\n- Is everything going as planned?\n- Has the expected end time changed?\n- Any unexpected impact?\n\n**For completed announcements:**\n- Did it finish on time?\n- Is everything back to normal?\n- Any follow-up actions needed from users?\n- Were there any unexpected issues during maintenance?\n\n### 4. Write the Announcement\n\nFollow these principles:\n\n#### Principle 1: Lead with what users need to do\nThe first sentence should tell users whether they need to take action.\n\n**Do:** \"Save any uncommitted work in Codespaces before Tuesday 16:00 UTC — we're performing scheduled maintenance that may interrupt active sessions.\"\n**Don't:** \"We will be performing scheduled maintenance on our infrastructure.\"\n\n#### Principle 2: Be specific about the impact\n\"May experience issues\" is not helpful. Tell users exactly what will and won't work.\n\n**Do:** \"During this window, new deployments will be paused. Existing deployments and live traffic will not be affected.\"\n**Don't:** \"Some services may be temporarily unavailable.\"\n\n#### Principle 3: Give the full time window in UTC\nInclude start time, end time, and expected duration. If the maintenance rolls out regionally, explain the order.\n\n**Do:** \"Maintenance window: Tuesday March 31, 02:00–04:00 UTC (approximately 2 hours). European regions will be maintained first, followed by US regions.\"\n**Don't:** \"Maintenance will happen Tuesday night.\"\n\n#### Principle 4: Announce early enough\nUsers need time to prepare. The lead time should match the severity of the impact:\n\n| Impact | Minimum lead time |\n|--------|------------------|\n| Full downtime | 72 hours (3 days) |\n| Degraded performance | 48 hours (2 days) |\n| Minimal/no user impact | 24 hours |\n\n#### Principle 5: In-progress and completed updates should add value\nMost companies post \"Scheduled maintenance is currently in progress\" and \"The scheduled maintenance has been completed\" — identical boilerplate every time. Do better.\n\n**In-progress — do:** \"Maintenance is underway. Database migration is running as expected. We're approximately 30 minutes in, targeting completion by 04:00 UTC.\"\n**In-progress — don't:** \"Scheduled maintenance is currently in progress.\"\n\n**Completed — do:** \"Maintenance completed at 03:45 UTC, 15 minutes ahead of schedule. All services are operational. No action needed from your side.\"\n**Completed — don't:** \"The scheduled maintenance has been completed.\"\n\n#### Principle 6: Communicate scope changes immediately\nIf maintenance takes longer than planned, post an update before the original end time.\n\n**Do:** \"Update: maintenance is taking longer than expected. New estimated completion: 05:30 UTC (originally 04:00 UTC). The delay is due to [reason]. [Impact during the extension].\"\n**Don't:** (silence past the original end time)\n\n## Phase Templates\n\n### Scheduled\n\n```\n**Scheduled Maintenance: [Component]**\n\n[Action users should take, if any, before the maintenance starts.]\n\n**When:** [Day, Date], [start time] – [end time] UTC (approximately [duration])\n**What's affected:** [Component(s)] — [specific user impact]\n**What's NOT affected:** [Unaffected services]\n**What to expect:** [Describe exactly what users will experience]\n\n[Preparation instructions or workarounds, if applicable.]\n\nWe'll post an update when maintenance begins and when it's complete.\n```\n\n### In-progress\n\n```\n**Maintenance In Progress: [Component]**\n\nScheduled maintenance on [Component] started at [start time] UTC.\n\n[Current status: what's happening right now, progress if known.]\nExpected completion: [end time] UTC.\n\n[Any unexpected impact or changes from the plan. If everything is on track: \"Everything is proceeding as planned.\"]\n```\n\n### Completed\n\n```\n**Maintenance Completed: [Component]**\n\nScheduled maintenance on [Component] was completed at [actual end time] UTC.\n\n[Did it finish on time, early, or late?]\nAll services are operating normally.\n[Any follow-up actions users need to take, e.g., \"You may need to refresh your dashboard\" or \"No action needed.\"]\n\n[If there were unexpected issues during maintenance, briefly note them and link to an incident if one was opened.]\n```\n\n### Extended\n\n```\n**Maintenance Extended: [Component]**\n\nScheduled maintenance on [Component] is taking longer than expected.\n\n**Original end time:** [time] UTC\n**New estimated end time:** [time] UTC\n**Reason:** [Brief explanation]\n\n[Updated user impact during the extension.]\nWe'll post another update at [time] UTC or when maintenance is complete.\n```\n\n### Cancelled\n\n```\n**Maintenance Cancelled: [Component]**\n\nThe scheduled maintenance for [Component] on [date, time window] UTC has been cancelled.\n\n**Reason:** [Brief explanation]\nNo action is needed. All services continue to operate normally.\n\n[If rescheduled: \"This maintenance will be rescheduled to [new date]. We'll send a new announcement with details.\"]\n```\n\n## Anti-patterns to Avoid\n\n| Anti-pattern | Why it's bad | Instead |\n|--------------|-------------|---------|\n| \"We will be performing scheduled maintenance\" as the opener | Buries the user action and impact | Lead with what users need to do or what they'll experience |\n| Same boilerplate for every maintenance | Users stop reading maintenance notices | Include specific impact and preparation steps |\n| \"Some services may be temporarily unavailable\" | Vague — users don't know if they're affected | Name the specific components and describe the impact |\n| No update after the original end time passes | Users don't know if it's still going or if you forgot | Always post an extension notice before the end time |\n| \"The scheduled maintenance has been completed\" (with no detail) | Missed opportunity to confirm normalcy and note any issues | State actual end time, whether everything is normal, and any user follow-up |\n| Announcing maintenance 1 hour before downtime | Users can't prepare | Follow the lead time guidelines based on impact severity |\n| \"Thank you for your patience\" | Empty filler | Replace with useful info: \"No action needed\" or \"You may need to re-authenticate\" |\n\n## Related Skills\n\n- `status-page-context` — Set up the context document this skill reads (components, maintenance windows, tone)\n- `incident-communication` — Write updates for unplanned incidents (not scheduled maintenance)\n- `status-report` — Write periodic health reports\n- `postmortem` — Write postmortems (only needed if maintenance caused an unplanned incident)\n\nFile v1.0.0:skills/postmortem/SKILL.md\n\n---\nname: postmortem\nversion: 0.1.0\ndescription: 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.\n---\n\n# Postmortem\n\nWrite blameless, actionable postmortems that help teams learn from incidents — not assign blame.\n\n## When to Use\n\n- \"write a postmortem for yesterday's outage\"\n- \"help me do an RCA for the API incident\"\n- \"we need an incident retrospective\"\n- After using `incident-communication` to resolve an incident\n\n## Workflow\n\n### 1. Check for Context\n\nRead `.agents/status-page-context.md` if it exists. Use it for:\n- **Component names** — reference the correct service names\n- **Severity levels** — classify the incident correctly\n- **Past patterns** — check if this is a recurring issue\n- **Tone** — match the team's communication style\n\nIf the file doesn't exist, suggest running the `status-page-context` skill first. Proceed without it if the user wants to skip.\n\n### 2. Determine Audience\n\nAsk the user who will read this postmortem:\n\n| Audience | What to emphasize |\n|----------|------------------|\n| **Internal (engineering team)** | Deep technical detail, code-level root cause, specific system names |\n| **Internal (leadership/cross-functional)** | Business impact, timeline, prevention measures, resource asks |\n| **External (customers/public)** | User impact, what was done, what's changing, trust rebuilding |\n\nDefault to **internal (engineering team)** if not specified.\n\n### 3. Gather Incident Details\n\nAsk for or extract from conversation:\n\n**Required (postmortem cannot proceed without these):**\n- What happened (high-level summary)\n- When it started and ended (UTC)\n- What was affected (components, users, regions)\n- What caused it (root cause, even if preliminary)\n- How it was fixed (mitigation steps)\n\n**Important (ask if not provided, mark `[TODO]` if unknown):**\n- Who detected it and how (monitoring alert, customer report, internal discovery)\n- Timeline of key events (detection, escalation, diagnosis, mitigation, resolution)\n- Quantified impact (error rates, affected users/requests, revenue impact)\n- Contributing factors beyond the root cause\n\n**Optional (include if available):**\n- On-call responders and roles\n- Links to relevant logs, dashboards, PRs\n- Screenshots or graphs showing the impact\n\n### 4. Write the Postmortem\n\nUse the template below. Fill in what you can from the information provided. Mark unknown sections with `[TODO: description of what's needed]` — never invent details.\n\n### 5. Review Checklist\n\nBefore delivering, verify:\n- [ ] Blameless language throughout (no \"Person X failed to...\")\n- [ ] Root cause goes deep enough (at least 2 \"why\"s deep)\n- [ ] Every action item has an owner placeholder and priority\n- [ ] Timeline has at least 4 entries (detection, identification, mitigation, resolution)\n- [ ] Impact is quantified where possible\n- [ ] \"What went well\" section is not empty\n\n## Postmortem Template\n\n```markdown\n# Postmortem: [Incident Title]\n\n**Date:** [YYYY-MM-DD]\n**Severity:** [Critical / Major / Minor]\n**Duration:** [X hours Y minutes] ([start time] – [end time] UTC)\n**Authors:** [TODO: who wrote this postmortem]\n**Status:** Draft\n\n---\n\n## Summary\n\n[2-3 sentences: what happened, what was affected, how long it lasted, and how it was resolved. Written so someone skimming only this paragraph gets the full picture.]\n\n## Impact\n\n- **Affected components:** [list]\n- **User impact:** [what users experienced]\n- **Duration:** [start] – [end] UTC ([total duration])\n- **Blast radius:** [% of users/requests affected, regions, plans]\n- **Data loss:** [yes/no — if yes, describe scope and recovery]\n- **SLA impact:** [did this breach any SLA commitments? error budget consumed?]\n- **Financial impact:** [TODO: revenue loss, credits issued, if applicable]\n\n## Timeline\n\nAll times in UTC.\n\n| Time | Event |\n|------|-------|\n| [HH:MM] | [First sign of issue — how it was detected] |\n| [HH:MM] | [Escalation — who was paged, who responded] |\n| [HH:MM] | [Key diagnostic step — what was investigated] |\n| [HH:MM] | [Root cause identified] |\n| [HH:MM] | [Mitigation applied — what was done] |\n| [HH:MM] | [Recovery confirmed — metrics returned to normal] |\n| [HH:MM] | [Incident declared resolved] |\n\n## Root Cause\n\n[Explain the root cause in plain language. Go at least 2 levels deep with \"why\":]\n\n**What happened:** [the direct technical cause]\n\n**Why it happened:** [the systemic reason the direct cause was possible]\n\n**Why that was possible:** [the deeper process/cultural/architectural gap]\n\n[If multiple contributing factors, list each separately.]\n\n## Detection\n\n- **How was it detected?** [monitoring alert / customer report / manual discovery]\n- **Time to detect:** [minutes from start to first alert]\n- **Was alerting effective?** [did the right alerts fire? were they actionable?]\n- **Detection gap:** [what should have caught this sooner?]\n\n## Response\n\n- **Time to first response:** [minutes from detection to first human action]\n- **Time to mitigation:** [minutes from detection to fix deployed]\n- **Time to resolution:** [minutes from detection to incident closed]\n- **Was the runbook followed?** [yes/no — if no, why not?]\n- **Escalation path:** [who was involved, was escalation timely?]\n\n## What Went Well\n\n- [Thing that worked — be specific]\n- [Thing that worked]\n- [Thing that worked]\n\n[This section is important. Teams that skip it only learn what to avoid, never what to repeat.]\n\n## What Went Wrong\n\n- [Thing that didn't work — be specific about the gap, not about people]\n- [Thing that didn't work]\n- [Thing that didn't work]\n\n## Where We Got Lucky\n\n- [Thing that could have made this worse but didn't]\n- [Thing that limited the blast radius by chance, not by design]\n\n[This section catches near-misses. If the incident had hit during peak traffic, during a deploy, or in a different region — would the impact have been worse?]\n\n## Action Items\n\n| Priority | Action | Owner | Due | Ticket |\n|----------|--------|-------|-----|--------|\n| P0 — must do | [Immediate fix to prevent exact recurrence] | [TODO] | [TODO] | [TODO] |\n| P0 — must do | [Improve detection for this failure mode] | [TODO] | [TODO] | [TODO] |\n| P1 — should do | [Systemic improvement to reduce risk] | [TODO] | [TODO] | [TODO] |\n| P2 — nice to have | [Longer-term architectural improvement] | [TODO] | [TODO] | [TODO] |\n\n## Lessons Learned\n\n[1-3 key takeaways that apply beyond this specific incident. What would you tell another team to watch out for?]\n\n---\n\n*This postmortem will be reviewed in the next incident review meeting on [TODO: date].*\n```\n\n## Blameless Writing Guide\n\nPostmortems exist to improve systems, not punish people. Every sentence should pass the blameless test:\n\n| Blameful (don't write) | Blameless (write this instead) |\n|----------------------|-------------------------------|\n| \"Engineer X forgot to check the config\" | \"The deployment process did not include a config validation step\" |\n| \"The on-call engineer was slow to respond\" | \"The alert routed to a secondary channel with a 20-minute delay\" |\n| \"QA missed this bug\" | \"The test suite did not cover this edge case\" |\n| \"Someone deployed without testing\" | \"The deploy pipeline does not enforce pre-deploy test runs\" |\n\n**The rule:** Replace the person with the system. If a human made an error, the system made it possible. Fix the system.\n\n## Root Cause Depth: The \"5 Whys\" Lite\n\nA postmortem that stops at the first \"why\" is a bug report, not a postmortem.\n\n**Too shallow:**\n> \"The API went down because a bad config was deployed.\"\n\n**Deep enough:**\n> \"The API went down because a bad config was deployed (why?). The bad config was deployed because config changes are not validated before deploy (why?). Config validation doesn't exist because configuration is managed as raw JSON with no schema (root cause: no config schema or validation in the deploy pipeline).\"\n\nGo at least 2-3 levels deep. Stop when you reach a systemic gap that can be addressed with an action item.\n\n## Related Skills\n\n- `incident-communication` — Write status updates during the incident (before the postmortem)\n- `status-page-context` — Set up the context document this skill reads (components, severity, past patterns)\n- `maintenance` — Write planned maintenance announcements\n- `status-report` — Write periodic health reports\n\nFile v1.0.0:skills/status-page-context/SKILL.md\n\n---\nname: status-page-context\nversion: 0.1.0\ndescription: 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.\n---\n\n# Status Page Context\n\nCreate and maintain `.agents/status-page-context.md` — the foundational context document referenced by all other status page skills.\n\n## When to Use\n\n- First time using any status page skill\n- \"set up my status page context\"\n- \"configure my incident communication style\"\n- \"update my SLA commitments\"\n- User wants to define components, tone, or escalation paths\n\n## Workflow\n\n### 1. Check for Existing Context\n\nLook for `.agents/status-page-context.md` in the project root.\n\n- **If it exists**: Read it and ask the user what they want to update.\n- **If it doesn't exist**: Offer two modes:\n  - **Auto-draft**: Scan the codebase for clues (README, config files, status page config, package.json) and pre-fill what you can.\n  - **Start from scratch**: Walk through each section interactively.\n\n### 2. Gather Context\n\nFor 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.\n\n### 3. Write the File\n\nWrite the completed context to `.agents/status-page-context.md`. Use the template below.\n\n## Context Template\n\n```markdown\n# Status Page Context\n\n*Last updated: [date]*\n\n## Service Overview\n**Company/Product name:**\n**One-liner:**\n**Status page URL:**\n**Primary audience:** (e.g., developers, enterprise customers, end users)\n\n## Components\nList every component shown on your status page.\n\n| Component | Description | Criticality |\n|-----------|-------------|-------------|\n| | | High / Medium / Low |\n\n## SLA & Uptime Commitments\n**Uptime target:** (e.g., 99.9%, 99.95%)\n**Response time SLA:** (e.g., acknowledge within 15 min, update every 30 min)\n**Maintenance window:** (e.g., Tuesdays 2-4am UTC)\n**SLA consequences:** (e.g., credits, contractual obligations)\n\n## Communication Tone\n**Style:** (formal / conversational / technical)\n**Voice characteristics:** (e.g., calm, transparent, empathetic, no corporate jargon)\n**Words to use:**\n-\n**Words to avoid:**\n-\n**Example good sentence:**\n> \"[example that sounds like your brand]\"\n\n## Severity Levels\n| Level | Criteria | Example |\n|-------|----------|---------|\n| Critical | Complete service outage or data loss | API returning 500 for all requests |\n| Major | Significant degradation affecting most users | Dashboard load times >10s |\n| Minor | Limited impact, workaround available | Webhook delays of 2-5 minutes |\n| Maintenance | Planned work, no unexpected impact | Scheduled database migration |\n\n## Escalation & Roles\n**Incident commander:** (role or person responsible for coordinating response)\n**Communications lead:** (who writes/approves status updates)\n**Update cadence:** (how often to post updates during an incident)\n**Approval required:** (yes/no — do updates need sign-off before publishing?)\n\n## Notification Channels\nWhere do status updates get published?\n- [ ] Status page\n- [ ] Email subscribers\n- [ ] Slack/Discord\n- [ ] Twitter/X\n- [ ] In-app banner\n- [ ] Other:\n\n## Past Patterns\n**Common incident types:**\n-\n**Recurring root causes:**\n-\n**Lessons from past incidents:**\n-\n```\n\n## Guidelines\n\n- **Be specific.** \"Conversational but professional\" is better than \"friendly.\"\n- **Include real examples.** A sample sentence in the right tone is worth more than a paragraph describing the tone.\n- **Components matter.** Downstream skills use the component list to scope incident updates and maintenance announcements.\n- **Severity levels drive behavior.** The `incident-communication` skill uses these to calibrate urgency and update frequency.\n- **Keep it current.** Re-run this skill when you add components, change SLAs, or shift communication style.\n\n## Related Skills\n\n- `incident-communication` — Write incident updates (uses this context for tone and components)\n- `postmortem` — Write blameless postmortems (uses this context for severity and past patterns)\n- `maintenance` — Write maintenance announcements (uses this context for components and maintenance windows)\n- `status-report` — Write periodic health reports (uses this context for components and SLA targets)\n\nFile v1.0.0:skills/status-report/SKILL.md\n\n---\nname: status-report\nversion: 0.1.0\ndescription: 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.\n---\n\n# Status Report\n\nWrite periodic status reports that give stakeholders a clear picture of system health, reliability trends, and what's being done to improve.\n\n## When to Use\n\n- \"write a weekly status report\"\n- \"draft our monthly uptime report\"\n- \"summarize system health for this quarter\"\n- \"write a reliability report for stakeholders\"\n\n## Workflow\n\n### 1. Check for Context\n\nRead `.agents/status-page-context.md` if it exists. Use it for:\n- **Component names** — report on the right services\n- **SLA targets** — compare actual uptime against commitments\n- **Severity levels** — classify incidents consistently\n- **Tone** — match the team's communication style\n\nIf the file doesn't exist, suggest running the `status-page-context` skill first. Proceed without it if the user wants to skip.\n\n### 2. Determine Report Type\n\nAsk the user if not obvious:\n\n| Type | Cadence | Audience | Focus |\n|------|---------|----------|-------|\n| **Weekly** | Every week | Internal team, stakeholders | Recent incidents, upcoming maintenance, quick health snapshot |\n| **Monthly** | Every month | Customers, leadership | Uptime metrics, incident summary, trends, improvements |\n| **Quarterly** | Every quarter | Leadership, board, customers | Reliability trends, SLA performance, strategic improvements |\n| **Ad-hoc** | As needed | Varies | Specific topic (e.g., post-migration health, new region launch) |\n\n### 3. Gather Data\n\nAsk the user for or help them collect:\n\n**Required:**\n- Reporting period (exact date range)\n- Uptime numbers per component (or overall)\n- Number and severity of incidents during the period\n- Any scheduled maintenance that occurred\n\n**Important (include if available):**\n- SLA target vs actual comparison\n- Error budget status (consumed/remaining)\n- Mean time to detect (MTTD), mean time to resolve (MTTR)\n- Incident trends (improving, stable, worsening)\n- Notable incidents with brief descriptions\n\n**Optional:**\n- Performance metrics (latency, throughput)\n- Upcoming planned maintenance\n- Reliability improvements shipped\n- Customer-reported issues\n\n### 4. Write the Report\n\nFollow these principles:\n\n#### Principle 1: Lead with the headline number\nThe first thing readers want to know: how did we do?\n\n**Do:** \"Overall uptime for March 2026: 99.97% (target: 99.9%). Zero critical incidents.\"\n**Don't:** Start with a paragraph about the team's efforts.\n\n#### Principle 2: Compare against targets\nRaw numbers without context are meaningless. Always compare to SLA targets or previous periods.\n\n**Do:** \"API uptime: 99.95% (target: 99.9%) — 0.05% above target. Error budget: 62% remaining.\"\n**Don't:** \"API uptime: 99.95%.\" (Is that good? Bad? On track?)\n\n#### Principle 3: Be honest about bad periods\nA status report that only highlights good metrics loses credibility. Address misses directly.\n\n**Do:** \"Webhook delivery uptime dropped to 99.2% this month, below our 99.5% target. This was driven by the March 14 incident (see below). We've shipped [fix] to prevent recurrence.\"\n**Don't:** Omit components that missed their targets.\n\n#### Principle 4: Show trends, not just snapshots\nOne month's number doesn't tell a story. Compare to previous periods.\n\n**Do:** \"MTTR improved from 45 min (Feb) to 28 min (Mar), driven by the new automated rollback system.\"\n**Don't:** \"MTTR: 28 minutes.\" (Better or worse than before?)\n\n#### Principle 5: Connect incidents to improvements\nEvery incident mentioned should link to what was done about it. This builds trust.\n\n**Do:** \"March 14 — Webhook delivery failure (47 min). Root cause: connection pool exhaustion. Fix shipped: automated pool scaling + alert at 80% capacity.\"\n**Don't:** \"March 14 — Webhook delivery failure (47 min).\" (And then?)\n\n#### Principle 6: End with what's next\nForward-looking items show the team is proactive, not just reactive.\n\n**Do:** \"Upcoming: Database migration (April 3, 02:00-04:00 UTC), new monitoring for edge regions, SLA review for Q2.\"\n**Don't:** End abruptly after the metrics.\n\n## Report Templates\n\n### Weekly Status Report\n\n```markdown\n# Weekly Status Report: [Date Range]\n\n## Summary\n[1-2 sentences: overall health this week. Lead with the headline.]\n\n## Uptime\n\n| Component | Uptime | Target | Status |\n|-----------|--------|--------|--------|\n| [Component] | [%] | [%] | [On target / Below target] |\n\n## Incidents This Week\n\n| Date | Severity | Component | Duration | Summary |\n|------|----------|-----------|----------|---------|\n| [Date] | [Sev] | [Component] | [Duration] | [One-line summary + fix status] |\n\n[If no incidents: \"No incidents this week.\"]\n\n## Maintenance\n\n| Date | Component | Duration | Status |\n|------|-----------|----------|--------|\n| [Date] | [Component] | [Duration] | [Completed / Scheduled] |\n\n## Looking Ahead\n- [Upcoming maintenance]\n- [Reliability improvements in progress]\n- [Anything the team should be aware of]\n```\n\n### Monthly Status Report\n\n```markdown\n# Monthly Status Report: [Month Year]\n\n## Executive Summary\n[2-3 sentences: how the month went, headline metrics, key events.]\n\n## Uptime & SLA Performance\n\n| Component | Uptime | SLA Target | vs Target | vs Last Month |\n|-----------|--------|------------|-----------|---------------|\n| [Component] | [%] | [%] | [+/- %] | [+/- %] |\n\n**Overall uptime:** [%]\n**Error budget consumed:** [%] ([remaining]% remaining for [period])\n\n## Reliability Metrics\n\n| Metric | This Month | Last Month | Trend |\n|--------|-----------|------------|-------|\n| Incidents (total) | [N] | [N] | [direction] |\n| Critical incidents | [N] | [N] | [direction] |\n| MTTD (mean time to detect) | [min] | [min] | [direction] |\n| MTTR (mean time to resolve) | [min] | [min] | [direction] |\n\n## Incident Summary\n\n### [Incident title] — [Date]\n- **Severity:** [Level]\n- **Duration:** [X min/hours]\n- **Impact:** [What users experienced]\n- **Root cause:** [1 sentence]\n- **Fix:** [What was done]\n- **Postmortem:** [Link or \"published\" or \"in progress\"]\n\n[Repeat for each notable incident. Minor incidents can be summarized in a table.]\n\n## Maintenance Summary\n\n[Table of maintenance windows with component, date, duration, outcome.]\n\n## Improvements Shipped\n\n- [Reliability improvement with brief description of what it prevents]\n- [Monitoring improvement]\n- [Process improvement]\n\n## Looking Ahead\n\n- **Upcoming maintenance:** [Dates and components]\n- **In progress:** [Reliability work underway]\n- **SLA review:** [Any target changes under consideration]\n\n---\n\n*Next report: [Date]*\n```\n\n### Quarterly Status Report\n\n```markdown\n# Quarterly Reliability Report: [Q# Year]\n\n## Executive Summary\n[3-5 sentences: quarter performance, key wins, key challenges, strategic outlook.]\n\n## Quarterly Metrics\n\n| Metric | Q[N] | Q[N-1] | Q[N-2] | Trend |\n|--------|------|--------|--------|-------|\n| Overall uptime | [%] | [%] | [%] | [direction] |\n| Critical incidents | [N] | [N] | [N] | [direction] |\n| Total incident minutes | [N] | [N] | [N] | [direction] |\n| MTTD | [min] | [min] | [min] | [direction] |\n| MTTR | [min] | [min] | [min] | [direction] |\n| Error budget remaining | [%] | [%] | [%] | [direction] |\n\n## SLA Performance by Component\n\n| Component | Q[N] Uptime | SLA Target | Met? |\n|-----------|-------------|------------|------|\n| [Component] | [%] | [%] | [Yes/No] |\n\n## Notable Incidents\n\n[Top 3-5 incidents by severity/impact with brief summaries and links to postmortems.]\n\n## Reliability Investments\n\n### Shipped This Quarter\n- [Initiative]: [Impact/result]\n\n### In Progress\n- [Initiative]: [Expected completion, expected impact]\n\n### Planned for Next Quarter\n- [Initiative]: [Why, expected impact]\n\n## Lessons Learned\n- [Key takeaway from the quarter's incidents]\n- [Pattern or trend identified]\n- [Process or cultural insight]\n\n## Outlook\n[2-3 sentences on focus areas for next quarter.]\n\n---\n\n*Next quarterly report: [Date]*\n```\n\n## Anti-patterns to Avoid\n\n| Anti-pattern | Why it's bad | Instead |\n|--------------|-------------|---------|\n| \"All systems operational\" with no data | Provides no transparency or accountability | Show uptime numbers against targets |\n| Only reporting good metrics | Erodes trust when stakeholders discover omissions | Address misses directly with root cause and fix |\n| Raw numbers without context | \"99.95%\" means nothing without the target | Always compare: vs target, vs last period |\n| Listing incidents without fixes | Feels like a problem list, not a report | Connect every incident to what was done about it |\n| Skipping months with no incidents | Inconsistency in reporting cadence | Still publish — \"No incidents this month\" is a positive signal |\n| Overly long reports | Nobody reads them | Keep weekly to 1 page, monthly to 2 pages, quarterly to 3-4 pages |\n\n## Related Skills\n\n- `status-page-context` — Set up the context document this skill reads (components, SLA targets, tone)\n- `incident-communication` — Write updates during active incidents (referenced in incident summaries)\n- `postmortem` — Write detailed postmortems (linked from incident summaries)\n- `maintenance` — Write maintenance announcements (referenced in maintenance summaries)\n\nFile v1.0.0:README.md\n\n# OpenStatus Skills for Agents\n\nStatus page & incident communication skills for AI agents — by [OpenStatus](https://openstatus.dev).\n\nWrite better incident updates, postmortems, maintenance announcements, and status reports.\n\n## Skills\n\n| Skill | What it does |\n|-------|-------------|\n| [`status-page-context`](skills/status-page-context/) | Configure your product, components, SLAs, severity levels, and communication tone. All other skills read this automatically. |\n| [`incident-communication`](skills/incident-communication/) | Write status page updates for any incident phase: investigating, identified, monitoring, resolved. |\n| [`postmortem`](skills/postmortem/) | Write blameless postmortems with timeline, root cause analysis (5 Whys), and prioritized action items. |\n| [`maintenance`](skills/maintenance/) | Write maintenance announcements: scheduled, in-progress, completed, extended, or cancelled. |\n| [`status-report`](skills/status-report/) | Write periodic health reports (weekly, monthly, quarterly) with uptime metrics, SLA tracking, and trends. |\n\n## How They Work Together\n\n```\nstatus-page-context     ← run this first (defines tone, components, SLAs)\n  │\n  ├── incident-communication   ← during an outage\n  │     investigating → identified → monitoring → resolved\n  │                                                  │\n  │                                                  └── postmortem   ← after resolution\n  │\n  ├── maintenance              ← for planned work\n  │     scheduled → in-progress → completed\n  │\n  └── status-report            ← periodic health updates\n        weekly / monthly / quarterly\n```\n\nEach skill checks for `.agents/status-page-context.md` and uses your defined tone, component names, and severity levels. Without it, skills still work — they'll just prompt you for the details.\n\n## What's Inside Each Skill\n\nEvery skill includes:\n\n- **SKILL.md** — full instructions, principles, templates, and anti-patterns\n- **references/examples.md** — real-world good and bad examples from Vercel, Stripe, GitHub, and Cloudflare\n- **references/framework.md** — checklists and quality tests to verify output\n- **evals/evals.json** — evaluation scenarios for testing skill behavior\n\n## Getting Started\n\n1. Install the skills using one of the methods above\n2. Run the `status-page-context` skill first to set up your product context\n3. Use any other skill — they'll automatically read your context for consistent tone and component names\n\n### Example: Write an incident update\n\n```\n> Our API is returning 500 errors, started about 10 minutes ago\n\nThe skill will:\n1. Check for your status-page-context\n2. Ask which phase you're in (or detect it from your message)\n3. Write a scoped update with timestamps, user impact, and next-update commitment\n4. Suggest the next phase when you're ready\n```\n\n---\n\nBuilt by [OpenStatus](https://openstatus.dev). Need help? Join our [Discord](https://openstatus.dev/discord) or message us at [ping@openstatus.dev](mailto:ping@openstatus.dev).\n\nFile v1.0.0:_meta.json\n\n{\n  \"ownerId\": \"kn74j27zmek8j1np3e8h6eh4sh84ym8c\",\n  \"slug\": \"incident-communication-playbook\",\n  \"version\": \"1.0.0\",\n  \"publishedAt\": 1776330643804\n}\n\nFile v1.0.0:skills/incident-communication/references/examples.md\n\n# Incident Communication — Good vs Bad Examples\n\nReal-world examples from public status pages, analyzed for what works and what doesn't.\n\n---\n\n## Investigating Phase\n\n### Bad: Too vague (GitHub pattern)\n\n> We are investigating reports of degraded performance for some GitHub services.\n\n**Problems:**\n- \"Some services\" — which ones?\n- \"Degraded performance\" — what does the user see?\n- No timestamp, no scope, no next-update commitment\n\n### Bad: Templated and robotic (Cloudflare pattern)\n\n> Cloudflare is investigating issues with network performance in Warsaw, Poland (WAW). We are working to analyse and mitigate this problem. More updates to follow shortly.\n\n**Problems:**\n- Third-person is unnecessarily formal\n- \"More updates to follow shortly\" — when exactly?\n- Doesn't say what users experience\n\n### Good: Scoped with user impact (Vercel pattern)\n\n> We are currently investigating reports of elevated error rates on the Vercel Dashboard. Existing deployments and live traffic are not affected by this issue. We will share updates as they become available.\n\n**Why it works:**\n- Names the affected component (Dashboard)\n- Immediately reassures about what's NOT affected (deployments, live traffic)\n- Users know whether they need to care\n\n### Good: Specific with timestamps (Stripe pattern)\n\n> We're currently observing elevated errors on the iDEAL payment method that began at 14:25 UTC. This issue is external to Stripe. We are actively monitoring the situation and will provide updates as more information becomes available.\n\n**Why it works:**\n- Exact start time in UTC\n- Names the specific payment method\n- Transparent about external cause\n- Concise\n\n### Best: Scoped + actionable\n\n> REST API requests to /v1/monitors are returning 503 errors starting at 14:25 UTC. The dashboard, status pages, and webhook delivery are operating normally. We're investigating the cause and will post an update within 30 minutes.\n\n**Why it's best:** Combines specific scope, user impact, blast radius, timestamp, and next-update commitment in 3 sentences.\n\n---\n\n## Identified Phase\n\n### Bad: Boilerplate (Cloudflare pattern)\n\n> The issue has been identified and a fix is being implemented.\n\n**Problems:**\n- What issue? What fix?\n- Identical text used for every incident regardless of severity\n- No ETA, no user guidance\n\n### Good: Explains cause and plan (Vercel pattern)\n\n> Some deployments created between 11:20 UTC and 15:14 UTC with Edge Middleware may be seeing elevated errors. Deployments created outside of this time window are unaffected. If you are experiencing issues, we recommend redeploying.\n\n**Why it works:**\n- Precise blast radius (time window + feature)\n- Clear \"not affected\" scope\n- Actionable workaround for users\n\n### Good: Progressive detail (GitHub Copilot Agent incident)\n\n> We are seeing widespread issues starting and viewing Copilot Agent sessions. We understand the cause and are working on remediation.\n\n**Why it works:**\n- Admits the scope is \"widespread\" (honest)\n- \"We understand the cause\" signals progress without overcommitting on details\n\n---\n\n## Monitoring Phase\n\n### Bad: Template with no detail\n\n> A fix has been implemented and we are monitoring the results.\n\n**Problems:**\n- What fix? How long will monitoring last?\n- Users don't know if they need to do anything\n\n### Good: Specific fix with timeline\n\n> We've rolled out a fix that excludes the Dubai region (dxb1) from deployment targets as a temporary measure. Builds should complete successfully again. We're monitoring for stability over the next 2 hours.\n\n**Why it works:**\n- Explains what the fix actually does\n- Sets a monitoring timeline\n- Tells users what to expect (\"builds should complete successfully\")\n\n---\n\n## Resolved Phase\n\n### Bad: No information (Cloudflare pattern)\n\n> This incident has been resolved.\n\n**Problems:**\n- No timeline, no cause, no impact summary\n- Users who missed the incident learn nothing\n- No postmortem commitment\n\n### Bad: Generic with empty empathy\n\n> This incident has been resolved. We apologize for any inconvenience this may have caused. Thank you for your patience.\n\n**Problems:**\n- Still no useful information\n- \"Apologize for any inconvenience\" is corporate filler\n\n### Good: Full summary with timestamps (Stripe pattern)\n\n> Between 14:25 - 14:45 UTC there was a disruption with the iDEAL payment method causing increased error rates for iDEAL transactions. The issue was external to Stripe and is now resolved.\n\n**Why it works:**\n- Exact time window\n- Clear cause attribution\n- Concise\n\n### Best: Complete resolved with postmortem (GitHub Copilot Agent incident)\n\n> On March 19, 2026, between 01:05 UTC and 02:52 UTC, and again on March 20, 2026, between 00:42 UTC and 01:58 UTC, the Copilot Coding Agent service was degraded and users were unable to start new Copilot Agent sessions or view existing ones. During the first incident, the average error rate was ~53% and peaked at ~93% of requests to the service. [...] Both incidents were caused by the same underlying system authentication issue that prevented the service from connecting to its backing datastore. We mitigated each incident by rotating the affected credentials [...] We are implementing automated monitoring for credential lifecycle events and improving operational processes to reduce our time to detection and mitigation.\n\n**Why it's best:**\n- Exact timestamps for both occurrences\n- Quantified impact (error rates with peaks)\n- Clear root cause explanation\n- Specific mitigation action\n- Forward-looking preventive measures\n\n---\n\n## Cross-cutting Patterns\n\n### What the best communicators do consistently:\n1. **Scope immediately** — name what's affected AND what's not (Vercel)\n2. **Timestamp everything** — exact UTC times, not \"recently\" (Stripe)\n3. **Give actionable guidance** — tell users what they can do (Vercel)\n4. **Each update adds information** — never repeat the same text (GitHub at its best)\n5. **Resolved = summary** — full timeline, cause, impact, next steps (Stripe, GitHub)\n6. **Attribute external causes** — be transparent about third-party issues (Stripe)\n\n### What the worst communicators do:\n1. **Copy-paste the same template** for every incident regardless of context (Cloudflare)\n2. **Stay vague** — \"some services,\" \"degraded performance\" (GitHub's first updates)\n3. **Repeat identical updates** — \"We are continuing to investigate\" 3x (Cloudflare Jakarta)\n4. **Empty resolved messages** — \"This incident has been resolved.\" (Cloudflare, Vercel sometimes)\n5. **Skip intermediate phases** — jump from investigating to resolved (Stripe sometimes)\n\nFile v1.0.0:skills/incident-communication/references/framework.md\n\n# Incident Communication — Framework & Checklist\n\n## Update Checklist by Phase\n\n### Investigating\n- [ ] Names the affected component(s)\n- [ ] Describes user-visible impact (what users see, not internal jargon)\n- [ ] States what is NOT affected\n- [ ] Includes start time in UTC\n- [ ] Commits to a next-update time\n- [ ] Does NOT speculate on cause (it's ok to say \"we're investigating\")\n\n### Identified\n- [ ] Explains root cause in plain language\n- [ ] States the fix plan or workaround\n- [ ] Provides ETA for fix, or explicitly says \"no ETA yet\"\n- [ ] Gives actionable guidance if users can mitigate (retry, switch region, redeploy)\n- [ ] Updates blast radius if it changed since investigating\n- [ ] Commits to next-update time\n\n### Monitoring\n- [ ] Explains what fix was deployed (1 sentence)\n- [ ] States when the fix was deployed (UTC)\n- [ ] Sets monitoring duration (\"next 2 hours\")\n- [ ] Tells users whether they need to take action\n- [ ] Notes any temporary workarounds still in place\n\n### Resolved\n- [ ] Includes exact start and end times in UTC\n- [ ] Summarizes root cause in 1-2 sentences\n- [ ] Describes what was done to fix it\n- [ ] Quantifies impact if possible (% of requests, # of users, duration)\n- [ ] States whether a postmortem will follow (and when)\n- [ ] Notes any ongoing preventive measures\n\n## Quality Checks\n\n### The \"3am test\"\nRead the update as if you're a customer seeing it at 3am with a production issue. Does it answer:\n1. Is my service affected?\n2. What should I do right now?\n3. When will I hear more?\n\nIf any answer is \"I don't know\" — rewrite.\n\n### The \"new information\" test\nCompare this update to the previous one. Does it contain at least one piece of new information? If not, either wait until you have something new, or explicitly acknowledge: \"No change since last update — we're still [action]. Next update at [time].\"\n\n### The \"specificity\" test\nSearch the update for these vague phrases and replace them:\n\n| Vague | Specific |\n|-------|----------|\n| \"some users\" | \"users in the EU region\" or \"~15% of API requests\" |\n| \"degraded performance\" | \"response times averaging 8s (normally <200ms)\" |\n| \"recently\" | \"starting at 14:25 UTC\" |\n| \"shortly\" | \"within 30 minutes\" |\n| \"some services\" | \"REST API and webhook delivery\" |\n| \"the issue\" | name the actual issue |\n\n### The \"empathy without filler\" test\nRemove any sentence that is purely empathetic without being informative:\n- Remove: \"We apologize for any inconvenience this may have caused.\"\n- Remove: \"Thank you for your patience.\"\n- Keep: \"We understand this impacts your production deployments and are prioritizing the fix.\"\n\nThe difference: the third sentence acknowledges impact AND signals action.\n\n## Severity → Update Cadence\n\n| Severity | First update | Subsequent updates | Monitoring duration |\n|----------|-------------|-------------------|-------------------|\n| Critical | Within 15 min of detection | Every 30 min minimum | 2-4 hours |\n| Major | Within 30 min | Every 60 min minimum | 1-2 hours |\n| Minor | Within 1 hour | Every 2 hours or as needed | 30-60 min |\n\nThese are defaults. Override with values from `.agents/status-page-context.md` if available.\n\n## Multi-update Incident Flow\n\nFor incidents lasting more than one update cycle:\n\n```\nUpdate 1 (Investigating): What's happening, who's affected, what's not\nUpdate 2 (Investigating): What we've learned, what we've ruled out\nUpdate 3 (Identified):    Root cause, fix plan, ETA\nUpdate 4 (Monitoring):    Fix deployed, what we're watching\nUpdate 5 (Resolved):      Full summary with timestamps and impact\n```\n\nEach update should reference the previous state: \"Since our last update, we've [new information].\"\n\n## Tone Calibration\n\n| Severity | Tone | Example opener |\n|----------|------|---------------|\n| Critical | Urgent, direct, frequent | \"API is returning 500 errors for all requests starting at 14:00 UTC.\" |\n| Major | Serious, clear, steady | \"Dashboard load times are significantly elevated, averaging 12s.\" |\n| Minor | Informative, calm | \"Webhook delivery is experiencing delays of 2-5 minutes.\" |\n\nRegardless of severity:\n- Be honest about what you don't know\n- Never minimize (\"just a small issue\") when users are affected\n- Never over-dramatize a minor issue\n\nFile v1.0.0:skills/maintenance/references/examples.md\n\n# Maintenance — Good vs Bad Examples\n\nReal-world examples from public status pages, analyzed for what works and what doesn't.\n\n---\n\n## Scheduled Announcements\n\n### Bad: Generic boilerplate (Cloudflare datacenter pattern)\n\n> We will be performing scheduled maintenance in ZRH (Zurich) datacenter on 2026-03-26 between 02:45 and 07:30 UTC. Traffic might be re-routed from this location, hence there is a possibility of a slight increase in latency during this maintenance window for end-users in the affected region.\n\n**Problems:**\n- Same template for every datacenter with only city/dates swapped\n- \"Possibility of a slight increase in latency\" — vague impact\n- No preparation steps for most users\n- Posted 24 minutes before start — far too late\n\n### Bad: Too sparse (Vercel pattern)\n\n> During this scheduled system maintenance by the registry, the following services may be unavailable for .COM and .NET domains:\n> - Availability Checks\n> - Domain Purchases\n> - Domain Renewals\n> - Domain Updates\n\n**Problems:**\n- No time window duration or expected end time\n- No workarounds\n- No preparation instructions\n- \"May be unavailable\" — will they or won't they?\n\n### Good: Complete with user actions (GitHub Codespaces pattern)\n\n> Codespaces will be undergoing global maintenance from 16:30 UTC on Wednesday, May 28 to 16:30 UTC on Thursday, May 29. Maintenance will begin in our Europe, Asia, and Australia regions. Once it is complete, maintenance will start in our US regions. Each batch of regions will take approximately three to four hours to complete.\n>\n> During this time period, users may experience intermittent connectivity issues when creating new Codespaces or accessing existing ones.\n>\n> To avoid disruptions, ensure that any uncommitted changes are committed and pushed before the maintenance starts. Codespaces with uncommitted changes will remain accessible as usual after the maintenance is complete.\n\n**Why it works:**\n- 6 days advance notice\n- Regional rollout order explained\n- Duration per batch specified\n- Clear user impact (\"intermittent connectivity issues when creating or accessing\")\n- Actionable preparation step (\"commit and push before it starts\")\n- Reassurance about data safety (\"uncommitted changes will remain accessible\")\n\n### Best: Leading with user action\n\n> Save any uncommitted work in Codespaces before Wednesday 16:30 UTC — we're performing global maintenance that may interrupt active sessions for 3-4 hours per region.\n>\n> **When:** Wednesday May 28, 16:30 UTC – Thursday May 29, 16:30 UTC\n> **Rollout order:** Europe/Asia/Australia first, then US (3-4 hours per batch)\n> **What's affected:** Creating new Codespaces, accessing existing ones (intermittent connectivity)\n> **What's NOT affected:** Repositories, PRs, Actions, GitHub.com\n> **Prepare:** Commit and push any uncommitted changes. Existing data is safe.\n\n**Why it's best:** Leads with the action users need to take. Structured for quick scanning. Explicitly states what's not affected.\n\n---\n\n## In-Progress Updates\n\n### Bad: Boilerplate (universal pattern)\n\n> Scheduled maintenance is currently in progress. We will provide updates as necessary.\n\n**Problems:**\n- Identical text used by GitHub, Cloudflare, and Vercel for every maintenance\n- No information about progress, current state, or revised ETA\n- Users have no idea if things are on track\n\n### Good: Progress update with status\n\n> Maintenance is underway on the database cluster. Migration of EU shards completed successfully. Now proceeding to US shards. Everything is on track for completion by 04:00 UTC.\n\n**Why it works:**\n- Shows progress (EU done, US next)\n- Confirms on-track status\n- Reaffirms expected end time\n\n### Good: Flagging unexpected issues early\n\n> Maintenance started at 02:00 UTC as scheduled. During the migration, we encountered an index rebuild that's taking longer than expected. Revising completion estimate to 05:00 UTC (originally 04:00 UTC). Live traffic is unaffected — only new deployments remain paused.\n\n**Why it works:**\n- Transparent about the delay before the original end time\n- Explains why\n- Confirms user impact hasn't changed\n\n---\n\n## Completed Announcements\n\n### Bad: No information (universal pattern)\n\n> The scheduled maintenance has been completed.\n\n**Problems:**\n- When did it actually finish? On time? Early? Late?\n- Is everything back to normal?\n- Do users need to do anything?\n- Were there any issues?\n\n### Good: Confirms normalcy with details\n\n> Maintenance on the database cluster completed at 03:45 UTC — 15 minutes ahead of schedule. All services are operational and performing normally. No action needed from your side.\n\n**Why it works:**\n- Exact completion time\n- Comparison to schedule (ahead/on time/late)\n- Explicit \"all services operational\" confirmation\n- Clear \"no action needed\"\n\n### Good: Completed with follow-up needed\n\n> Maintenance completed at 04:30 UTC (30 minutes past the originally scheduled 04:00 UTC). All services are operational. The delay was caused by an additional index rebuild that was identified during the migration.\n>\n> **Action needed:** If you created API keys between 02:00 and 04:30 UTC, they may need to be regenerated. All other keys are unaffected.\n\n**Why it works:**\n- Honest about the delay and why\n- Specific follow-up action for affected users\n- Scopes who needs to act (only users who created keys during the window)\n\n---\n\n## Extended Maintenance\n\n### Bad: Silence past the end time\n\n(No update posted. Original end time was 04:00 UTC. It's now 04:30 UTC.)\n\n**Problems:**\n- Users don't know if maintenance is still happening or if you forgot\n- Trust erodes rapidly when published timelines are missed without communication\n\n### Good: Proactive extension notice\n\n> Update: Database maintenance is taking longer than expected due to an additional migration step we identified.\n>\n> **Original end time:** 04:00 UTC\n> **New estimated end time:** 05:30 UTC\n> **Impact remains the same:** New deployments are paused. Existing deployments and live traffic are unaffected.\n>\n> We'll post another update at 05:00 UTC or when complete.\n\n**Why it works:**\n- Posted before the original end time\n- Explains the reason\n- Confirms impact hasn't changed\n- Sets next update time\n\n---\n\n## Cancelled Maintenance\n\n### Bad: Vague cancellation\n\n> The scheduled maintenance has been cancelled.\n\n### Good: Explains why and what's next\n\n> The database maintenance scheduled for Tuesday March 31, 02:00–04:00 UTC has been cancelled. We identified a potential issue with the migration script during pre-checks and want to resolve it before proceeding.\n>\n> This maintenance will be rescheduled to next week. We'll send a new announcement with the updated window.\n\n**Why it works:**\n- Names the specific maintenance (not just \"the maintenance\")\n- Explains why it's cancelled (shows diligence, not disorganization)\n- Sets expectation for rescheduling\n\nFile v1.0.0:skills/maintenance/references/framework.md\n\n# Maintenance — Framework & Checklist\n\n## Announcement Checklist by Phase\n\n### Scheduled\n- [ ] Specific component(s) named\n- [ ] Start and end time in UTC\n- [ ] Expected duration stated\n- [ ] User impact described (what will/won't work)\n- [ ] What's NOT affected is explicitly stated\n- [ ] Preparation steps or workarounds provided (if applicable)\n- [ ] Lead time is appropriate for the impact severity\n- [ ] Commitment to update when maintenance starts and completes\n\n### In-progress\n- [ ] Confirms maintenance has started at [time] UTC\n- [ ] States current progress (not just \"in progress\")\n- [ ] Reaffirms or updates the expected end time\n- [ ] Notes any unexpected issues or scope changes\n- [ ] Confirms current user impact matches expectations\n\n### Completed\n- [ ] States actual completion time in UTC\n- [ ] Notes whether it finished on time, early, or late\n- [ ] Confirms all services are back to normal (or describes exceptions)\n- [ ] States any follow-up user action needed (or explicitly \"no action needed\")\n- [ ] Mentions any issues encountered during maintenance (if relevant)\n\n### Extended\n- [ ] Posted BEFORE the original end time passes\n- [ ] States original and new estimated end time\n- [ ] Explains reason for the extension\n- [ ] Confirms whether user impact has changed\n- [ ] Sets time for next update\n\n### Cancelled\n- [ ] References the specific maintenance (date, time, component)\n- [ ] Explains why it's cancelled\n- [ ] States whether it will be rescheduled\n- [ ] Confirms no impact to current services\n\n## Lead Time Guide\n\n| User impact | Minimum notice | Recommended notice |\n|-------------|---------------|-------------------|\n| Full downtime of a critical service | 72 hours | 1 week |\n| Degraded performance or partial downtime | 48 hours | 3-5 days |\n| Minimal impact (latency increase, background jobs delayed) | 24 hours | 48 hours |\n| No user-visible impact | 12 hours | 24 hours |\n\nIf the context file defines a standard maintenance window (e.g., \"Tuesdays 02:00-04:00 UTC\"), reference it — users who know the window will still appreciate the specific announcement.\n\n## Quality Checks\n\n### The \"Should I worry?\" Test\nRead the scheduled announcement as a user. Within 10 seconds, can you answer:\n1. Am I affected?\n2. When is it happening?\n3. Do I need to do anything?\n\nIf any answer is unclear, rewrite.\n\n### The \"Silence\" Test\nFor in-progress and completed phases: does the update contain at least one piece of information beyond the phase change itself? \"Maintenance is in progress\" fails. \"Maintenance is in progress, EU migration complete, US next, on track for 04:00 UTC\" passes.\n\n### The \"Clock\" Test\nCheck all timestamps:\n- All times in UTC?\n- Start AND end times included?\n- Duration stated (not just start/end)?\n- If regional rollout: order and per-region timing included?\n\n### The \"Preparation\" Test\nFor scheduled announcements with user-visible impact:\n- Is there a specific action users should take before maintenance?\n- Is there a workaround during maintenance?\n- Is there a follow-up action after maintenance?\n\nIf any of these exist but aren't mentioned, add them.\n\n## Maintenance Communication Timeline\n\n```\nDay -7 to -3:  Post scheduled announcement (for significant maintenance)\nDay -1:        Post reminder if maintenance was announced >3 days ago\nHour -1:       Post \"starting in 60 minutes\" reminder\nMinute 0:      Post in-progress update with status\nMid-point:     Post progress update (for maintenance >2 hours)\nEnd time:      Post completed update OR extension notice\nAfter:         Update context file if this revealed patterns\n```\n\n## When Maintenance Becomes an Incident\n\nIf maintenance causes unexpected issues:\n1. Post a maintenance update acknowledging the problem\n2. Open a separate incident for the unexpected issue\n3. Link the incident to the maintenance\n4. Use the `incident-communication` skill for the incident updates\n5. After both are resolved, decide if a `postmortem` is needed\n\n**Trigger:** Maintenance becomes an incident when the impact exceeds what was announced, affects services that were listed as \"not affected,\" or extends significantly beyond the planned window without a clear path to completion.\n\n## Recurring Maintenance Patterns\n\nIf the same type of maintenance happens regularly (e.g., monthly certificate rotation, weekly database cleanup):\n\n- **Create a template** specific to that maintenance type\n- **Reference previous instances** (\"similar to our March 15 maintenance\")\n- **Note improvements** if the process has gotten better (\"this month's window is 2 hours, down from 4 hours last month thanks to [improvement]\")\n- **Don't copy-paste blindly** — even recurring maintenance deserves specific details for each instance\n\nFile v1.0.0:skills/postmortem/references/examples.md\n\n# Postmortem — Good vs Bad Examples\n\n---\n\n## Summary Section\n\n### Bad: Vague and defensive\n\n> We experienced some issues with our API on Tuesday. The team worked hard to resolve it and everything is back to normal now.\n\n**Problems:**\n- \"Some issues\" — what issues?\n- \"Tuesday\" — what time?\n- \"Worked hard\" — describes effort, not what happened\n- No mention of impact, cause, or duration\n\n### Good: Complete picture in 3 sentences\n\n> On March 19, 2026, between 01:05 and 02:52 UTC, the Copilot Coding Agent service was degraded. Users were unable to start new agent sessions or view existing ones, with error rates peaking at 93% of requests. The incident was caused by a system authentication issue that prevented the service from connecting to its backing datastore, and was mitigated by rotating the affected credentials.\n\n**Why it works:**\n- Exact date and time window\n- Specific user impact with quantified error rates\n- Root cause and fix in one sentence\n- Anyone reading just this paragraph understands the full incident\n\n---\n\n## Timeline Section\n\n### Bad: Too sparse\n\n| Time | Event |\n|------|-------|\n| 14:00 | Issue started |\n| 15:00 | Issue fixed |\n\n**Problems:**\n- Only 2 entries — no story of what happened in between\n- No detection, escalation, or diagnostic steps\n\n### Good: Tells the story of the response\n\n| Time | Event |\n|------|-------|\n| 14:02 | Monitoring alert fires: API error rate >5% |\n| 14:05 | On-call engineer acknowledges alert, begins investigation |\n| 14:12 | Identifies elevated 503s on /v1/checks endpoint |\n| 14:18 | Correlates with deployment at 13:58 — config change to connection pool |\n| 14:22 | Decides to roll back deployment |\n| 14:25 | Rollback initiated |\n| 14:31 | Error rates return to baseline |\n| 14:45 | Monitoring confirms stability, incident marked resolved |\n\n**Why it works:**\n- Shows detection → diagnosis → decision → action → confirmation\n- Each entry adds information\n- Timestamps show response speed (3 min to acknowledge, 16 min to identify cause)\n\n---\n\n## Root Cause Section\n\n### Bad: Stops at the surface\n\n> A bad configuration was deployed that caused the API to crash.\n\n**Problems:**\n- \"Bad configuration\" — what was bad about it?\n- Only 1 level of \"why\"\n- No systemic insight\n\n### Bad: Blames a person\n\n> An engineer deployed a configuration change without testing it in staging first, which brought down the API.\n\n**Problems:**\n- Names a human as the cause\n- Suggests the fix is \"tell the engineer to be more careful\"\n- Misses the systemic question: why was untested deployment possible?\n\n### Good: Goes 3 levels deep, stays blameless\n\n> **What happened:** The API connection pool size was reduced from 100 to 10 in a configuration change, causing connection exhaustion under normal load.\n>\n> **Why it happened:** The configuration change was applied directly to production. The staging environment uses a different config file format and was not updated, so the change was never tested under realistic load.\n>\n> **Why that was possible:** Configuration is managed as raw JSON files with no schema validation. There is no CI check that compares staging and production config parity, and the deploy pipeline does not enforce staging-first deployment for config changes.\n\n**Why it works:**\n- Each level reveals a deeper systemic gap\n- No person is blamed — the system allowed the error\n- Action items write themselves: add config schema, add parity checks, enforce staging deploys\n\n---\n\n## Action Items Section\n\n### Bad: Vague with no ownership\n\n| Action |\n|--------|\n| Fix the config |\n| Be more careful with deployments |\n| Add more monitoring |\n\n**Problems:**\n- No owner, no due date, no priority\n- \"Be more careful\" is not an action item\n- \"Add more monitoring\" — of what?\n\n### Good: Specific, owned, prioritized\n\n| Priority | Action | Owner | Due | Ticket |\n|----------|--------|-------|-----|--------|\n| P0 | Add JSON schema validation for API config files | [TODO: platform team] | [TODO: 1 week] | [TODO] |\n| P0 | Add alerting for connection pool exhaustion (< 20% available) | [TODO: SRE] | [TODO: 1 week] | [TODO] |\n| P1 | Enforce staging-first deployment for config changes in CI | [TODO: platform team] | [TODO: 2 weeks] | [TODO] |\n| P2 | Audit all config files for staging/production parity | [TODO: platform team] | [TODO: 1 month] | [TODO] |\n\n**Why it works:**\n- Each action prevents a specific failure mode\n- P0 items prevent exact recurrence\n- P1/P2 items address systemic gaps\n- Owner and due date ensure follow-through (even as TODO placeholders)\n\n---\n\n## \"What Went Well\" Section\n\n### Bad: Empty or filler\n\n> Everything went well in the response.\n\n### Good: Specific and reinforcing\n\n> - **Monitoring caught it fast.** The error rate alert fired within 2 minutes of the bad deploy. Detection time was excellent.\n> - **Rollback was quick.** The team decided to roll back within 6 minutes of identifying the cause, rather than attempting a forward fix. This was the right call.\n> - **Communication was timely.** The first status page update was posted within 10 minutes of detection, and updates followed every 15 minutes.\n\n**Why it works:** Specific observations that the team can repeat. Highlights good decisions and good systems, not just good luck.\n\n---\n\n## \"Where We Got Lucky\" Section\n\n### Bad: Omitted entirely\n\nMost postmortems skip this section. That's a missed opportunity to catch near-misses.\n\n### Good: Surfaces hidden risks\n\n> - **This happened during low-traffic hours (2am UTC).** If the same deploy had gone out at peak traffic (14:00 UTC), the impact would have been ~10x worse with user-facing errors in the thousands.\n> - **Only one endpoint was affected.** The config change happened to only impact the /v1/checks connection pool. If it had been applied to the shared pool, all API endpoints would have gone down.\n> - **The on-call engineer had debugged a similar issue last month.** Pattern recognition sped up diagnosis. If a different engineer had been on-call, time-to-identify could have been significantly longer.\n\n**Why it works:** Each item identifies a fragility. Action items should address these: deploy restrictions during peak hours, shared pool protections, runbook for connection issues.\n\n---\n\n## Blameless vs Blameful — Full Example\n\n### Blameful version (don't write this):\n\n> **Root cause:** John deployed the config change directly to production without going through staging. He also didn't notice the error in the connection pool value. The team should have caught this in code review but nobody reviewed the change carefully enough.\n\n### Blameless version (write this):\n\n> **Root cause:** A configuration change reducing the connection pool size was applied to production without passing through the staging environment. The deploy pipeline allows direct-to-production config changes, and config files lack schema validation that would catch out-of-range values. Code review for config changes does not have a required checklist for verifying staging parity.\n\n**The difference:** The blameless version identifies three systemic gaps (pipeline allows bypass, no schema validation, no review checklist) that can each become an action item. The blameful version identifies one person who can only be told \"don't do that again.\"","readmeExcerpt":"Skill: Status page & incident communication by openstatus Owner: openstatus Summary: Write professional incident updates, blameless postmortems, maintenance announcements, and status reports for your status page. Includes real-world examples... Tags: latest:1.0.0 Version history: v1.0.0 | 2026-04-16T09:10:43.804Z | user Initial release of incident-communication skill. - Enables writing professional incident updates f","codeSnippets":[],"executableExamples":[{"language":"text","snippet":"[Component] is experiencing [user-visible impact] starting at [time UTC].\n[What is NOT affected].\nWe are investigating the cause and will provide an update by [time/timeframe]."},{"language":"text","snippet":"We've identified the cause of [brief description of issue affecting Component].\n[Root cause in plain language].\nWe are [action being taken] and expect [recovery ETA or \"will update when we have an ETA\"].\n[What users can do in the meantime, if anything].\nNext update by [time/timeframe]."},{"language":"text","snippet":"A fix for [brief issue description] has been deployed at [time UTC].\n[What the fix was, in one sentence].\nWe are monitoring for stability and will resolve this incident if no further issues arise within [timeframe].\n[Any user action needed, e.g., \"no action needed\" or \"you may need to retry failed requests\"]."},{"language":"text","snippet":"Between [start time] and [end time] UTC, [Component] experienced [user-visible impact].\n[Root cause in 1-2 sentences].\n[What was done to fix it].\n[Impact summary: % of users/requests affected, if known].\n[Postmortem commitment: \"We'll publish a detailed postmortem within [timeframe]\" or \"No further action needed\"]."},{"language":"text","snippet":"**Scheduled Maintenance: [Component]**\n\n[Action users should take, if any, before the maintenance starts.]\n\n**When:** [Day, Date], [start time] – [end time] UTC (approximately [duration])\n**What's affected:** [Component(s)] — [specific user impact]\n**What's NOT affected:** [Unaffected services]\n**What to expect:** [Describe exactly what users will experience]\n\n[Preparation instructions or workarounds, if applicable.]\n\nWe'll post an update when maintenance begins and when it's complete."},{"language":"text","snippet":"**Maintenance In Progress: [Component]**\n\nScheduled maintenance on [Component] started at [start time] UTC.\n\n[Current status: what's happening right now, progress if known.]\nExpected completion: [end time] UTC.\n\n[Any unexpected impact or changes from the plan. If everything is on track: \"Everything is proceeding as planned.\"]"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"skills/incident-communication/SKILL.md","content":"---\nname: incident-communication\nversion: 0.1.0\ndescription: 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.\n---\n\n# Incident Communication\n\nWrite status page updates that are clear, honest, and useful — for any phase of an incident.\n\n## When to Use\n\n- \"write an incident update\"\n- \"we have an API outage, help me communicate it\"\n- \"draft a resolved update for the database incident\"\n- \"our webhooks are delayed, what should I post?\"\n\n## Workflow\n\n### 1. Check for Context\n\nRead `.agents/status-page-context.md` if it exists. Use it for:\n- **Tone and voice** — match the team's communication style\n- **Components** — reference the correct component names\n- **Severity levels** — calibrate urgency appropriately\n- **Update cadence** — respect the team's SLA for update frequency\n\nIf the file doesn't exist, suggest running the `status-page-context` skill first. Proceed without it if the user wants to skip.\n\n### 2. Determine the Phase\n\nAsk the user which phase they're in if not obvious from their message:\n\n| Phase | When | Purpose |\n|-------|------|---------|\n| **Investigating** | Something is wrong, cause unknown | Acknowledge the issue, set expectations |\n| **Identified** | Root cause found, fix in progress | Explain what's happening, share the plan |\n| **Monitoring** | Fix deployed, watching for stability | Confirm the fix, set recovery expectations |\n| **Resolved** | Incident is over | Summarize what happened with exact timeframes |\n\n### 3. Gather Incident Details\n\nFor any phase, you need:\n- **What's affected** — which components/services (use names from context if available)\n- **What's the user impact** — what are users experiencing? (errors, slowness, data loss)\n- **What's NOT affected** — critical for reducing panic\n- **What's being done** — current actions being taken\n\nAdditional details by phase:\n- **Investigating:** When did it start? Who reported it?\n- **Identified:** What's the root cause? What's the fix plan? ETA?\n- **Monitoring:** What fix was deployed? How long will monitoring last?\n- **Resolved:** Exact start/end times (UTC). What was the root cause? Will there be a postmortem?\n\n### 4. Write the Update\n\nFollow these principles (in priority order):\n\n#### Principle 1: Scope the blast radius immediately\nThe first sentence should tell users what's affected AND what's not.\n\n**Do:** \"REST API requests are returning elevated 5xx errors. The dashboard and webhook delivery are operating normally.\"\n**Don't:** \"We are investigating reports of degraded performance for some services.\"\n\n#### Principle 2: Be specific about user impact\nDescribe what users are experiencing, not just what's broken internally.\n\n**Do:** \"Deployments created between 11:20 and 15:14 UTC may be fail"},{"path":"skills/maintenance/SKILL.md","content":"---\nname: maintenance\nversion: 0.1.0\ndescription: 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.\n---\n\n# Maintenance\n\nWrite maintenance announcements that give users everything they need to prepare, stay informed, and confirm completion.\n\n## When to Use\n\n- \"write a maintenance announcement\"\n- \"we have database maintenance next Tuesday\"\n- \"draft a maintenance-in-progress update\"\n- \"announce that the maintenance is done\"\n\n## Workflow\n\n### 1. Check for Context\n\nRead `.agents/status-page-context.md` if it exists. Use it for:\n- **Component names** — reference the correct service names\n- **Maintenance window** — default schedule if one is defined\n- **Tone** — match the team's communication style\n- **Notification channels** — remind about where to publish\n\nIf the file doesn't exist, suggest running the `status-page-context` skill first. Proceed without it if the user wants to skip.\n\n### 2. Determine the Phase\n\nAsk the user which phase if not obvious:\n\n| Phase | When | Purpose |\n|-------|------|---------|\n| **Scheduled** | Before the maintenance | Give users time to prepare |\n| **In-progress** | Maintenance has started | Confirm it's happening, set expectations |\n| **Completed** | Maintenance is done | Confirm everything is back to normal |\n| **Cancelled** | Maintenance won't happen | Inform users the planned work is called off |\n| **Extended** | Maintenance is running longer than planned | Update the expected end time |\n\n### 3. Gather Details\n\n**For scheduled announcements:**\n- What components/services are affected?\n- What is the maintenance window? (start time, end time, timezone — always convert to UTC)\n- What will users experience? (full downtime, degraded performance, intermittent errors)\n- What should users do to prepare? (save work, expect delays, switch regions)\n- How far in advance is this being announced?\n- Is there a workaround during the maintenance?\n\n**For in-progress updates:**\n- Is everything going as planned?\n- Has the expected end time changed?\n- Any unexpected impact?\n\n**For completed announcements:**\n- Did it finish on time?\n- Is everything back to normal?\n- Any follow-up actions needed from users?\n- Were there any unexpected issues during maintenance?\n\n### 4. Write the Announcement\n\nFollow these principles:\n\n#### Principle 1: Lead with what users need to do\nThe first sentence should tell users whether they need to take action.\n\n**Do:** \"Save any uncommitted work in Codespaces before Tuesday 16:00 UTC — we're performing scheduled maintenance that may interrupt active sessions.\"\n**Don't:** \"We will be performing scheduled maintenance on our infrastructure.\"\n\n#### Principle 2: Be specific about the impact\n\"May experience issues\" is not helpful. Tell users exactly what will and won't work.\n\n**"},{"path":"skills/postmortem/SKILL.md","content":"---\nname: postmortem\nversion: 0.1.0\ndescription: 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.\n---\n\n# Postmortem\n\nWrite blameless, actionable postmortems that help teams learn from incidents — not assign blame.\n\n## When to Use\n\n- \"write a postmortem for yesterday's outage\"\n- \"help me do an RCA for the API incident\"\n- \"we need an incident retrospective\"\n- After using `incident-communication` to resolve an incident\n\n## Workflow\n\n### 1. Check for Context\n\nRead `.agents/status-page-context.md` if it exists. Use it for:\n- **Component names** — reference the correct service names\n- **Severity levels** — classify the incident correctly\n- **Past patterns** — check if this is a recurring issue\n- **Tone** — match the team's communication style\n\nIf the file doesn't exist, suggest running the `status-page-context` skill first. Proceed without it if the user wants to skip.\n\n### 2. Determine Audience\n\nAsk the user who will read this postmortem:\n\n| Audience | What to emphasize |\n|----------|------------------|\n| **Internal (engineering team)** | Deep technical detail, code-level root cause, specific system names |\n| **Internal (leadership/cross-functional)** | Business impact, timeline, prevention measures, resource asks |\n| **External (customers/public)** | User impact, what was done, what's changing, trust rebuilding |\n\nDefault to **internal (engineering team)** if not specified.\n\n### 3. Gather Incident Details\n\nAsk for or extract from conversation:\n\n**Required (postmortem cannot proceed without these):**\n- What happened (high-level summary)\n- When it started and ended (UTC)\n- What was affected (components, users, regions)\n- What caused it (root cause, even if preliminary)\n- How it was fixed (mitigation steps)\n\n**Important (ask if not provided, mark `[TODO]` if unknown):**\n- Who detected it and how (monitoring alert, customer report, internal discovery)\n- Timeline of key events (detection, escalation, diagnosis, mitigation, resolution)\n- Quantified impact (error rates, affected users/requests, revenue impact)\n- Contributing factors beyond the root cause\n\n**Optional (include if available):**\n- On-call responders and roles\n- Links to relevant logs, dashboards, PRs\n- Screenshots or graphs showing the impact\n\n### 4. Write the Postmortem\n\nUse the template below. Fill in what you can from the information provided. Mark unknown sections with `[TODO: description of what's needed]` — never invent details.\n\n### 5. Review Checklist\n\nBefore delivering, verify:\n- [ ] Blameless language throughout (no \"Person X failed to...\")\n- [ ] Root cause goes deep enough (at least 2 \"why\"s deep)\n- [ ] Every action item has an owner placeholder and priority\n- [ ] Timeline has at least 4 entries (detection, identifi"},{"path":"skills/status-page-context/SKILL.md","content":"---\nname: status-page-context\nversion: 0.1.0\ndescription: 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.\n---\n\n# Status Page Context\n\nCreate and maintain `.agents/status-page-context.md` — the foundational context document referenced by all other status page skills.\n\n## When to Use\n\n- First time using any status page skill\n- \"set up my status page context\"\n- \"configure my incident communication style\"\n- \"update my SLA commitments\"\n- User wants to define components, tone, or escalation paths\n\n## Workflow\n\n### 1. Check for Existing Context\n\nLook for `.agents/status-page-context.md` in the project root.\n\n- **If it exists**: Read it and ask the user what they want to update.\n- **If it doesn't exist**: Offer two modes:\n  - **Auto-draft**: Scan the codebase for clues (README, config files, status page config, package.json) and pre-fill what you can.\n  - **Start from scratch**: Walk through each section interactively.\n\n### 2. Gather Context\n\nFor 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.\n\n### 3. Write the File\n\nWrite the completed context to `.agents/status-page-context.md`. Use the template below.\n\n## Context Template\n\n```markdown\n# Status Page Context\n\n*Last updated: [date]*\n\n## Service Overview\n**Company/Product name:**\n**One-liner:**\n**Status page URL:**\n**Primary audience:** (e.g., developers, enterprise customers, end users)\n\n## Components\nList every component shown on your status page.\n\n| Component | Description | Criticality |\n|-----------|-------------|-------------|\n| | | High / Medium / Low |\n\n## SLA & Uptime Commitments\n**Uptime target:** (e.g., 99.9%, 99.95%)\n**Response time SLA:** (e.g., acknowledge within 15 min, update every 30 min)\n**Maintenance window:** (e.g., Tuesdays 2-4am UTC)\n**SLA consequences:** (e.g., credits, contractual obligations)\n\n## Communication Tone\n**Style:** (formal / conversational / technical)\n**Voice characteristics:** (e.g., calm, transparent, empathetic, no corporate jargon)\n**Words to use:**\n-\n**Words to avoid:**\n-\n**Example good sentence:**\n> \"[example that sounds like your brand]\"\n\n## Severity Levels\n| Level | Criteria | Example |\n|-------|----------|---------|\n| Critical | Complete service outage or data loss | API returning 500 for all requests |\n| Major | Significant degradation affecting most users | Dashboard load times >10s |\n| Minor | Limited impact, workaround available | Webhook delays of 2-5 minutes |\n| Maintenance | Planned work, no unexpected impact | Scheduled database migration |\n\n## Escalation & Roles\n**Incident commander:** (role or person responsible for coordinating response)\n**Communications lead:** (who w"},{"path":"skills/status-report/SKILL.md","content":"---\nname: status-report\nversion: 0.1.0\ndescription: 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.\n---\n\n# Status Report\n\nWrite periodic status reports that give stakeholders a clear picture of system health, reliability trends, and what's being done to improve.\n\n## When to Use\n\n- \"write a weekly status report\"\n- \"draft our monthly uptime report\"\n- \"summarize system health for this quarter\"\n- \"write a reliability report for stakeholders\"\n\n## Workflow\n\n### 1. Check for Context\n\nRead `.agents/status-page-context.md` if it exists. Use it for:\n- **Component names** — report on the right services\n- **SLA targets** — compare actual uptime against commitments\n- **Severity levels** — classify incidents consistently\n- **Tone** — match the team's communication style\n\nIf the file doesn't exist, suggest running the `status-page-context` skill first. Proceed without it if the user wants to skip.\n\n### 2. Determine Report Type\n\nAsk the user if not obvious:\n\n| Type | Cadence | Audience | Focus |\n|------|---------|----------|-------|\n| **Weekly** | Every week | Internal team, stakeholders | Recent incidents, upcoming maintenance, quick health snapshot |\n| **Monthly** | Every month | Customers, leadership | Uptime metrics, incident summary, trends, improvements |\n| **Quarterly** | Every quarter | Leadership, board, customers | Reliability trends, SLA performance, strategic improvements |\n| **Ad-hoc** | As needed | Varies | Specific topic (e.g., post-migration health, new region launch) |\n\n### 3. Gather Data\n\nAsk the user for or help them collect:\n\n**Required:**\n- Reporting period (exact date range)\n- Uptime numbers per component (or overall)\n- Number and severity of incidents during the period\n- Any scheduled maintenance that occurred\n\n**Important (include if available):**\n- SLA target vs actual comparison\n- Error budget status (consumed/remaining)\n- Mean time to detect (MTTD), mean time to resolve (MTTR)\n- Incident trends (improving, stable, worsening)\n- Notable incidents with brief descriptions\n\n**Optional:**\n- Performance metrics (latency, throughput)\n- Upcoming planned maintenance\n- Reliability improvements shipped\n- Customer-reported issues\n\n### 4. Write the Report\n\nFollow these principles:\n\n#### Principle 1: Lead with the headline number\nThe first thing readers want to know: how did we do?\n\n**Do:** \"Overall uptime for March 2026: 99.97% (target: 99.9%). Zero critical incidents.\"\n**Don't:** Start with a paragraph about the team's efforts.\n\n#### Principle 2: Compare against targets\nRaw numbers without context are meaningless. Always compare to SLA targets or previous periods.\n\n**Do:** \"API uptime: 99.95% (target: 99.9%) — 0.05% above target. Error budget: 62% remaining.\"\n**Don'"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":null,"editorialQuality":{"score":100,"threshold":65,"status":"thin","wordCount":2445,"uniquenessScore":38,"reasons":["uniqueness-below-45"]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T06:12:45.655Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T06:12:45.655Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-11T08:43:15.594Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}