Turn a workflow in your head into a runbook anyone can run.
A step-by-step SOP for a repeated process, who does what, when, and how, with named failure points and a check on every step.
Inside: The full who-what-when-how capture, stranger-followable steps, and a check per step.
Install it in one line, or paste it in.
~/.claude/skills/ and runs automatically when it is relevant.Connect your context. Set it to your motion.
the runbook is stored where the team already looks, versioned and linkable.
recurring runs become a checklist that can be assigned and tracked.
the runbook cross-links to the facts and stakeholders it depends on.
This was built for an operator ready to hand a repeated task off. Set these to your setup:
The 5W2H frame is fixed. What each W points at is yours.
| Set this | What it is | Default / Example |
|---|---|---|
| RB_HOME | where runbooks live | a git repo/runbooks; a notes tool |
| ROLE | who runs it | a rolenot a person's name |
| TRIGGER | what starts the run | a schedulean eventa request |
| TOOLS | the systems a step touches | your CRMa sheeta task tool |
| CHECK_STYLE | how a step is verified | a visible outputa counta confirmation |
| COST_UNIT | how "how much" is measured | minutesAPI callsdollars |
Everything the skill does, in full.
Takes a process you run from memory and turns it into a runbook someone else can execute without you. It captures the full 5W2H, who does it, what they do, when it runs, where it happens, why it matters, how each step is performed, and how much it costs in time or money, then it marks where it usually breaks and the check that confirms each step actually worked. The test of a runbook is simple: could a capable person you have never met run this correctly? This builds to that bar.
- 15W2H capture
Every runbook answers seven questions. Who runs it (a role, never a single person, so it survives turnover). What the outcome is. When it triggers. Where it happens (which systems). Why it matters (so a runner knows when to stop if the reason is gone). How, the numbered steps. How much, the time or cost per run. Skip one and the runbook has a hole a stranger will fall into.
- 2Steps a stranger can follow
Each step is an action with an object: "export the signup list from the sheet," not "get the data." No step assumes context only you have. Where a step needs a fact, it links to it rather than assuming the reader knows.
- 3Failure points, named
For each step that tends to break, say so, and say what breaking looks like. "The sheet read times out on runs over 5k rows" is a failure point. Naming it turns a mystery outage into an expected, handled case.
- 4Checks that prove it worked
Every step that matters ends with a check: the visible output, the row count, the confirmation message that says it succeeded. A runbook without checks is a wish list. A runner should never have to guess whether a step landed.
- 5Roles, not names
The runbook names a role, not a person. When the person changes, the runbook still runs. Personal contact details live in the knowledge base and are linked, not hard-coded into the steps.
- Nothing is saved or published without your explicit approval. The skill drafts the runbook and shows it; you decide where it lands.
- No step without a check. If a step cannot be verified, that is called out as a risk, not left silent.
- Failure points are named, not hidden. A known break that is undocumented is a trap for the next runner.
- Roles, not names. A runbook that depends on one person by name is flagged to be generalized.
RUNBOOK · Nightly signup enrichment + routing · v1 (draft) WHO the RevOps on-call role (not a named person) WHAT enrich each new signup and route it to an owner WHEN nightly, 2am, after the raw signups sync lands WHERE the signups sheet -> the enrichment tool -> the CRM WHY the AE team works this list first thing; stale = missed speed-to-lead HOW MUCH ~8 min unattended; ~1,200 API calls/run HOW (steps) 1. Confirm the raw sync landed. CHECK: row count > 0 in "signups-raw" 2. Run enrichment on new rows. CHECK: email fill rate reported 3. Route by company-size band. CHECK: every row has an owner 4. Post the run summary. CHECK: summary message in the channel FAILURE POINTS - Step 2 times out over ~5k rows. If so, batch in chunks of 2k. - Step 3 leaves EU signups unrouted (no owner rule yet). Flag, do not drop. (draft, not saved. approve to store in the runbooks home)
Where an operator takes this next.
The draft proves the process can leave your head. Here is the version that survives without you.
The next person who runs this doesn't need to call you to find out what step 3 means.
Push the approved runbook into your team's git repo or notes tool so it's linked, versioned, and findable at 2am.
Connect a task tool so each nightly run creates a trackable checklist instead of a static doc nobody checks off.
Wire step 2's row-count check to Slack so a timeout gets flagged the moment it happens, not the next morning.
One skill is the on-ramp.
A single skill does one job. Chained into a playbook, or run as a full build, it becomes a system. Here is where this one plugs in.