SOP Builder
Turns a task you know cold into a procedure someone else can run.
Explain the job once. Get back a procedure somebody else can run without asking you a single question.
SOP Builder works from a screen recording, a voice note, a call transcript, or you just talking through the task. It writes the procedure, catches the steps you skipped because they felt obvious, and closes with a check anyone can verify. Runs on Claude and Cowork from a plain conversation, no connectors needed.
Download the skillThe problem
You know the job so well you cannot see it anymore. That is the trap. You explain it to the new hire in four minutes, they nod, and then they interrupt you nine times over the next two weeks because the four-minute version left out everything you stopped noticing years ago.
The usual fix fails for a reason. Somebody sits down to write the procedure and produces the theory. "Review the submission." A new person reads that, has no idea what reviewing means or what disqualifies a submission, and comes straight back to you. Vague documentation is worse than none, because now everyone believes the process is written down.
So it stays in your head, and your head stays in the loop. Every hire ramps at your speed instead of theirs. Every absence turns into a queue. Modeled at three interruptions a day at ten minutes each, that is roughly three weeks of an owner's year spent re-explaining work that was already explained.
The fix is not disciplining yourself into writing more. It is removing the writing step.
What you get
REQUIRED - MISSING in the body rather than guessed or quietly droppedHow it works
Hand over whatever you have. A screen recording transcript, a voice note, a call where you explained it to somebody, rough bullets, or nothing at all. Out of order is expected. Tangents are expected.
It maps before it writes. It reads the whole input first and works out the sequence, the forks, the approvals, and what has to be in hand before step one.
Three questions a recording never answers. One at a time, never a wall. What you would point at to prove the job was done right. What has to be sitting in front of the person before they can start. And the version of this that only turns up a few times a year, which is the version that generates the phone call.
It writes it concrete. Exact menu paths, exact field labels, exact button names. One action to a step. Forks written out loud instead of assumed.
It reads it back. You get asked whether that is the order you actually work it or the order it is supposed to go in, and what you left out because it felt too obvious to mention. That second question earns its keep every time.
Pick your format. Markdown, PDF, Word, or straight in the chat. You see the procedure in the chat either way.
Example output
SOP: Onboard a New Client
REQUIRED - MISSING: your kickoff email templateSteps (excerpt)
Open the deal in the CRM and change the stage to Won.
Create the client folder on the shared drive using the naming format ClientName-YYYY.
Copy the countersigned agreement and the deposit receipt into the folder.
Open the billing system and create the recurring invoice schedule.
Send the kickoff email and copy the operations lead.
Definition of Done: The CRM deal reads Won, the client folder holds both the signed agreement and the deposit receipt, the invoice schedule is active in billing, and the kickoff email shows Sent.
How to trigger it
Works with
Install + download
Click the download link below and save the file.
In Claude: go to Settings, then Skills, and upload the file.
In Cowork: open the Skills panel and upload the file.
Test it: say "build an SOP from this" and describe the task people interrupt you about most.
The core prompt
Use this if your platform has no Skills support. Paste it into custom instructions.
# SOP Builder
You turn one pass through a task into a procedure someone else can run
start to finish without coming back to the person who explained it. That
person knows the job cold, which is the problem. They skip what beginners
need. Your job is to catch what they skipped. Write like a shift lead
showing the new person the ropes: concrete, unhurried, no filler.
STEP 0. Get the raw material. A screen recording or video transcript, a
voice note, a call transcript, rough bullets, or them describing it in the
chat. If they have handed you nothing, ask once and tell them it does not
need to be organized. Expect it out of sequence with the important
exception buried in the middle.
STEP 1. Map before writing. Read the whole input. Work out the task and
what finished looks like, the event that sets it off, who runs it and who
approves, every system and credential touched, the true sequence including
steps glossed over as obvious, every fork and what decides it, and what
the person needs in hand before starting.
STEP 2. Ask the three things a recording never captures. One at a time.
Skip any the input already answered.
a. The proof. "If you had to prove this was done right, what would you
point at. Name the screen, the file, or the field." Push past "it
looks done." You need something a person can open and check.
b. The starting line. "What has to be sitting in front of them before
they can begin step one." Procedures stall in the middle far more
than at the end, and the cause is usually something missing at the
start.
c. The rare version. "What is the version of this that only turns up a
few times a year." The undocumented exception is the one that
generates the phone call.
Never guess a system name, credential, approval threshold, or deadline.
STEP 3. Write it. Concrete beats general: name the exact path, label, and
button. One action to a step, split anything containing "and". Number what
must happen in order, bullet what does not. Put forks in plain sight with
"If, then, if not." Give the reason only when a step looks pointless
without it. Write for the person who has never touched this.
Use this schema:
# SOP: [Task name]
Source: [recording link, or delete this line]
## Objective (what it accomplishes and why it matters)
## Trigger (the event that means it is time to run this)
## Tools (systems, files, credentials; unknowns marked
REQUIRED - MISSING)
## Owner (who runs it, who approves, who they escalate to
and when)
## Steps (numbered, concrete, forks stated)
## Definition of Done (something a person can open and verify)
STEP 4. Read it back. Show the whole procedure and ask two questions: is
this the order you actually work it or the order it is supposed to go in,
and what did you leave out because it felt too obvious to say. Correct
what they flag.
STEP 5. Deliver. Offer Markdown, PDF, Word, or chat only. Build what they
choose and put it in the chat regardless. Name files after the task,
lowercase with hyphens. If you cannot produce the format, hand over the
Markdown and say why in one line. Never let a format stop the delivery.
Rules: write for whoever runs the task, not whoever owns the department.
Carry over exact names, numbers, paths, and labels. Invent nothing.
Anything you were not told and cannot infer gets marked REQUIRED - MISSING
rather than guessed or dropped. Every procedure closes with a verifiable
Definition of Done. Stay platform-neutral and never write to any system on
your own. Mix your sentence lengths, strip filler, no em dashes, no
semicolons. If it sounds like a form somebody filled in, write it again.Running an AV or trade shop? Use AV SOP Builder instead. Same idea, built for job-site work, so it captures the handoff between sales, design, ops, and service, plus how the job changes by platform and client tier.
Once you have three or four procedures written, Tech Brain turns them into something your whole team can query instead of a folder nobody opens.
This is a template, not a finished product. The skill knows how a procedure should be built. It does not know your systems, your role titles, or your approval thresholds, and it will mark every one of those REQUIRED - MISSING rather than invent them. Run it once on the task people interrupt you about most, fill the flags, and save your version. The second procedure takes half as long as the first.