runbook
Create or update a runbook for an operational scenario — an incident an alert fires for, a recurring scheduled task, or a known failure mode on a live service — using a consistent template. Use when writing, drafting, authoring, or updating a runbook for an alert, incident, on-call procedure, scheduled maintenance, or operational SOP. Applies a YAGNI preflight requiring the scenario to be real before producing the runbook. Does not produce feature or system documentation — use project-documentation. Does not record architectural decisions — use architectural-decision-record. Does not create co
npx skills add testdouble/han --skill runbook --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# Create or Update Runbook ## Operating Principles - **YAGNI applies to runbooks themselves.** Apply the evidence-based YAGNI rule from [../../references/yagni-rule.md](../../references/yagni-rule.md). A runbook is worth writing only when the scenario is grounded in something real: an alert that has actually fired, a documented incident, a recurring task that exists, or a known failure mode on a service that receives production traffic. Runbooks for hypothetical alerts, "best practice says we should have one," or "we'll need this someday" are YAGNI candidates and the runbook should be deferred until the scenario actually occurs. The canonical anti-pattern from project history: Sentry runbooks for staging-only Sentry where data isn't reaching production — alerts that will never fire because no signal flows. The user always wins; the rule's job is to make the cost of speculative runbooks visible. - **The companion evidence rule applies to the runbook's supporting evidence.** Apply the evidence rule from [../../references/evidence-rule.md](../../references/evidence-rule.md) to the citations that ground the scenario: name the trust class of each piece of evidence (alert history, incide
- Operating Principles
- Project Context
- Step 1: Determine Mode
- Step 2: Apply the YAGNI Preflight
- Step 3: Discover Project Structure
- Step 4: Gather Context
- Step 5: Write the Runbook
- Step 6: Integration
- Step 7: Verification
- Step 8: Readability Self-Check
What does the runbook skill do?
Create or update a runbook for an operational scenario — an incident an alert fires for, a recurring scheduled task, or a known failure mode on a live service — using a consistent template. Use when writing, drafting, authoring, or updating a runbook for an alert, incident, on-call procedure, scheduled maintenance, or operational SOP. Applies a YAGNI preflight requiring the scenario to be real before producing the runbook. Does not produce feature or system documentation — use project-documentation. Does not record architectural decisions — use architectural-decision-record. Does not create co
How do I install it?
Run `npx skills add testdouble/han --skill runbook --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From testdouble/han, a repository with 154 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.