Turn a workflow in your head into a runbook anyone can run.

“Everything I run lives in my head. What happens when I am out for a week?”

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.

RUN THE OPERATOR SYSTEMEASY✓ APPROVED 4/4
EXAMPLE PROMPTS
>Turn how I run our weekly pipeline review into a runbook someone else can follow
>Write an SOP for this process. I will talk through it: [describes steps]
>Where does this runbook usually break, and what check should confirm each step worked?
ABOUT THIS SKILL

What this skill does

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.

Inputs

  • Works today with: your description of the process, or a rough list of steps. It structures it into a full runbook.
  • More powerful connected to a repo or notes tool: the runbook is stored where the team already looks, versioned and linkable.
  • Sharper with a task tool: recurring runs become a checklist that can be assigned and tracked.
  • Sharper with a knowledge base: the runbook cross-links to the facts and stakeholders it depends on.

How it works

  1. 1
    5W2H 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.

  2. 2
    Steps 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.

  3. 3
    Failure 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.

  4. 4
    Checks 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.

  5. 5
    Roles, 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.

Output format

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)

Tips

  • 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.
RELATED SKILLS
NO SETUPEASY · Operator System & Context

Turn a cold start into a warm one with one doc.

A single pack that tells a new session or teammate what the project is, where things live, what's decided, and the next move.

RUNS ON WHAT YOU PASTEAPPROVED · INSTALL →
NO SETUPEASY · Operator System & Context

Capture the session context so you can resume it cold.

An end-of-session brief: progress, decisions, unfinished items with next steps, and the fragile details, then it asks whether to save.

RUNS ON WHAT YOU PASTEAPPROVED · INSTALL →
ALL RUN THE OPERATOR SYSTEM SKILLS →