Agent skills for writing SOPs
Most standard operating procedures are never written, because writing one costs an hour that the person who knows the process does not have. A skill takes a walkthrough, spoken or recorded, and turns it into a numbered procedure with the decision points marked. You correct it in ten minutes instead of writing it in sixty.
Talk through it once, correct it once
The input that works best is the least effort: do the task while narrating it, badly, including the bits where you say "and then you have to remember that Fridays are different". Those asides are the whole reason a written SOP is worth having, and they never survive being typed up formally.
> turn recordings/new-vendor-setup.txt into an SOP
using templates/sop.md# SOP: Setting up a new vendor
Owner: operations Reviewed: 2026-08-23
Runs: whenever a signed vendor agreement arrives
## Before you start
- signed agreement (PDF)
- W-9 or local equivalent
- the requester's cost centre
## Steps
1. Create the vendor record. Legal name from the
agreement, not the email signature.
2. Attach the agreement and the tax form to the record.
3. Set payment terms from the agreement. If the
agreement is silent, use the default and note it.
4. DECISION: is this vendor over the approval
threshold? If yes, route to finance before step 5.
5. Add to the payment run calendar.
## Known exceptions
- Requests arriving Friday afternoon miss the weekly
run and go out the following Thursday.
- Overseas vendors need the bank detail check first,
which takes two days.
## [UNCLEAR] flagged for the owner
- Step 3: what is "the default" if terms are silent?
- Who approves an overseas vendor when finance is out?Why the flagged section matters more than the steps
A procedure written from a walkthrough always has holes, because the person narrating knows the answer and does not say it out loud. A skill that guesses at those holes produces a document that looks finished and teaches the next person the wrong thing. A skill instructed to mark them and stop produces a shorter document and a list of two questions, which is the honest state of the process.
Write that instruction into the skill file explicitly. Left unsaid, the default behaviour is to fill the gap with something plausible.
What makes an SOP get followed
One owner and a review date at the top.
An unowned procedure is out of date within a quarter and nobody is wrong about it. Put both in the template so the skill fills them every time.
Decision points called out, not buried.
The steps anyone can follow are not the risky ones. Marking the branch, in capitals, in line, is what stops a new person guessing.
The exceptions section.
The Friday rule, the two-day check, the one client who is invoiced differently. This section is why people keep asking the person instead of reading the document.
Short enough to read standing up.
A twelve-step SOP is used. A three-page SOP is a document about a process, which is a different and less useful thing.
Point it at the SOPs you already have first
Before generating new procedures, run the skill over two you wrote by hand and compare. Where it produces a different structure, either your template is unclear or the skill's instructions are, and it is cheaper to find that out on a document whose correct answer you already know. The approach generalises: see the guide on testing whether a skill actually works.
Works with Claude Code.
The Small ops team pack
Fifteen skills for SOPs, weekly reviews, handoffs and vendor follow-ups, with the templates and the eval cases included so you can see what was tested. The pack page carries the price, the refund terms, and the date everything was last tested.
See the packs