operations-runbooklisted

Create operations runbooks and a troubleshooting guide for a software project — how to run it, how to monitor it, and exactly what to do when something breaks. Produces one action-first runbook per component (Markdown, repo-first) with a failure-mode entry per thing that can go wrong, plus monitoring signals, routine operations, and escalation. Use this whenever the user wants a runbook, ops guide, on-call doc, troubleshooting guide, incident playbook, SRE doc, "what to do when X fails", or wants to document how to operate, monitor, and recover their service. Use it even if the user only says "write the runbook for this", "document operations and on-call", or "how do we recover when it goes down". Built for projects that include AI components (model cost, drift, guardrails) as well as ordinary services. Operator-facing — not an end-user how-to (usage-guide), design rationale (architecture-and-decisions), or look-up Q&A (project-faq).
imrohitagrawal/project-doc-skills · ★ 0 · AI & Automation · score 58

Install: claude install-skill imrohitagrawal/project-doc-skills

# Operations Runbook Builder Build the **operator-facing** documentation: how to run the system, what to watch, and the exact steps to recover when it breaks. A runbook is read under pressure, so it is action-first and concrete. Read `references/house-style.md` first. The default scope is `internal` (operators and on-call), so naming the real tools and commands is expected. **Diátaxis mode:** a blend of *how-to* (recovery procedures) and *reference* (signals, thresholds, contacts). Keep procedures imperative and scannable. --- ## Before you start (inputs, timing, and where this sits) **What this needs as input.** One or more components that are far enough along to operate — they build, deploy, and emit some signal (logs, metrics, or traces). For each component: its failure modes (the failure-mode analysis or FMEA the design work produced), its dependencies, the dashboards and alerts, and where the live service-level objectives and error budget are tracked — you **link** those, you do not restate the numbers. Plus the project profile (`assets/project-profile.md`). **When to run it — per component, as each one becomes operable. Not on an empty repo, not every commit.** A runbook describes how a thing behaves when it runs, so it can only be truthful once the thing runs. Write or refresh a component's runbook when that component reaches its Definition of Done (it deploys and you can watch it), then **walk the recovery steps through once** — an untested runbook is a guess. R