‹ Back to the directory

SOP Writer

Write step-by-step SOPs a new hire can run alone: observable steps, explicit branches, exceptions, and an escalation path.

by Copperseam·0 installs
sopproceduresoperationsdocumentation
F

Create a free shareskills account to install SOP Writer into Claude.

Create a free account

SOP Writer

A standard operating procedure earns its name only if a competent new hire can execute it alone, first try, without tapping anyone on the shoulder. This skill interviews for the missing context, writes steps as observable actions with expected results, forces judgment calls into explicit branches, and wraps it all in the boring metadata — owner, version, review date — that keeps a procedure alive after its author moves on.

When to use this skill

  • A process lives in one person's head and must be written down before it walks out the door
  • An existing SOP keeps generating the same questions, which means it is not yet an SOP
  • A new tool, workflow, or compliance obligation needs a repeatable documented procedure
  • Onboarding needs task documentation a first-week hire can follow unassisted
  • An audit or certification requires procedures with named owners and review dates

Workflow

  1. Run the scope interview before writing: what event triggers the procedure, who performs it, what observable state means done, how often it runs, and what tends to go wrong. If the user cannot name the trigger, the SOP will be shelfware — push until the trigger is an event.
  2. Walk the happy path once, end to end, capturing each step as actor + action + object + expected result: "Operator submits the request form — expect: a confirmation reference on screen."
  3. Enforce one action per step. "Save and email the file" is two steps, because it can fail in two different places, and the failure report will say "step 7" either way.
  4. Convert every judgment call into an explicit branch: "If the amount exceeds the threshold, go to step 9; otherwise continue." Unstated judgment is where SOPs rot first.
  5. Give exceptions their own section — the three to five likeliest failures, each with a response and a named escalation contact. An SOP with no exceptions section has never met reality.
  6. Add the survival metadata: owner (a role, not a person, unless the org is tiny), version, last-reviewed date, and a review cadence with the next date already computed.
  7. Test by inversion: simulate a reader who knows nothing and execute the SOP literally. Every place you had to assume something, the text gains a step, a definition, or a marker for a screenshot.
  8. Deliver in the template below, and keep it under a ten-minute read — beyond that, split it into a parent procedure that hands off to sub-procedures.

Output format

# SOP: <name>
Owner (role): · Version: · Last reviewed: · Review due:
Trigger: <the event that starts this procedure>
Performed by: <role> · Approved by: <role>
Done means: <observable end state>

## Steps
1. <Actor> <does what, to what> — expect: <observable result>
2. If <condition>: go to step <n>. Otherwise continue.
...

## Exceptions
| If this happens | Do this | Escalate to |
|-----------------|---------|-------------|

## Definitions
<terms a first-week hire would not know>

Quality bar

  • Every step names an actor and ends in a result someone can see, hear, or verify.
  • No step depends on tribal knowledge; anything unwritten gets written or defined.
  • Branches are exhaustive at every decision point — there is always an "otherwise".
  • Escalation contacts are roles with a channel attached, not "ask around".
  • The inversion test passes: executed literally, the procedure reaches done without improvising.
SOP Writer — AI skill by Copperseam | shareskills