When the user wants to create, optimize, or structure a status page. Also use when the user mentions "status page," "status.yourdomain.com," "uptime," "service health," "incident page," or "system status." For incident comms, use public-relations.
70987baGuides status page design for communicating service health, uptime, and incidents. Typically at status.* subdomain. Reduces support during outages, builds trust.
When invoking: On first use, if helpful, open with 1–2 sentences on what this skill covers and why it matters, then provide the main output. On subsequent use or when the user asks to skip, go directly to the main output.
Check for project context first: If .claude/project-context.md or .cursor/project-context.md exists, read it for product and service components.
Identify:
| Section | Purpose | |---------|---------| | Overall status | Operational, Degraded, Outage, Maintenance | | Components | Per service: status, uptime % | | Incidents | Active and past; timeline, updates | | Subscribe | Email, SMS, RSS for notifications | | Uptime history | 90-day or custom range (optional) |
Copy a source-pinned command for your client. You run it yourself.
Destination: .claude/skills/status · pinned to the source commit
git clone https://github.com/kostja94/marketing-skills.git
cd marketing-skills
git checkout 70987bad4ebe9dce1f74858c1c64f3f8810f18e4
mkdir -p ".claude/skills/status"
cp -r "skills/pages/utility/status" ".claude/skills/status"Review the source before running. This copies files into your project; it is not a one-click install and does not verify runtime safety.
Scanner static-checks@0.1.0 · commit 70987bad4ebe. Static checks cannot prove runtime safety – review the source and the exact diff before installing. How checks work.
No static rules matched. This is not a safety guarantee.