AV SOP Builder
Turns one walkthrough into a process your team runs without calling you.
Talk through the job once. Get back a process your team can run without calling you.
AV SOP Builder takes a screen recording, a voice memo from the truck, or you just explaining the task out loud, and turns it into a written process with the handoff named, the failure modes flagged, and the variants spelled out. Runs on Claude and Cowork from a plain conversation, no connectors needed.
Download the skillThe problem
The process lives in your head, so every job routes through you. A tech calls from the site because nobody wrote down which closet the head end goes in on this builder's homes. A coordinator pings you because she does not know who approves a change order under a thousand dollars. You answer, the job moves, and nothing got written down. Next month the next person asks the same question.
When shops do try to document it, they write the theory. "Confirm the prewire." A new tech reads that and still calls you, because confirm against what. The steps are too vague to follow, so the SOP gets written once, saved to a folder, and never opened again.
The cost does not show up as a documentation line item. It shows up as truck rolls. A tech who guesses wrong on a rack layout or a keypad program does not fail quietly, he fails on a return visit, on your dime, in front of the client. Modeled at one avoidable callback a week at three hours plus drive time, that is a technician's month disappearing every year into work that was already done once.
The fix is not writing better SOPs. It is never writing one from a blank page again.
What you get
How it works
Shop standards check. First question every run: do you have a sheet with your tool names, role titles, sign-off authority, and file naming. Paste it and every SOP comes back in your vocabulary. Skip it and the skill runs in placeholder mode, full structure with every shop-specific value stamped for you to fill.
Dump the walkthrough. Paste a recording transcript, a voice memo from the truck, a phone call where you explained it to someone, or just talk through the job in the chat. Out of order is fine. Tangents are fine.
It maps before it writes. It reads the whole thing first and works out the sequence, the branches, and where the work leaves your hands and lands in someone else's.
Four questions a recording never answers. One at a time, never a wall. What you look at to know it is done. Whether the job forks by platform or client tier. How you find out when it was done wrong. Who gets it next and what they need from you.
Ceiling counts where they apply. When the task has a budget, rack units, network ports, amp channels, zones, keypad buttons, licenses, the SOP gets a counting step before the work is called done.
Read it back. It shows you the draft and asks whether that is the order you actually run it or the order you wish you ran it, then asks for the exception you did not mention because it only comes up twice a year. That second question surfaces more than the first.
Pick your format. Markdown, PDF, Word, or straight in the chat. It shows you the SOP in the chat either way.
Example output
SOP: Rack Build to Field Handoff
Mode: Placeholder
Runs on: New construction and major retrofit. Does not apply to single-room service work.
Who: Runs it, rack technician. Signs off, project manager. Escalates to lead programmer when a processor arrives with firmware older than the project baseline.
Before You Start: Approved rack elevation, all equipment received and serial-logged, REQUIRED - MISSING: your rack labeling standard, network addressing sheet from the programmer.
Steps (excerpt)
Where This Goes Wrong: Ports get terminated to the drawing instead of the as-built, and the mismatch is found on site at step 7 rather than in the shop. You find out when the tech calls from the job asking which run is which.
Definition of Done: Every device answers on its assigned address from a laptop on the rack switch, the elevation photo is in the job folder, and the PM has acknowledged the handoff.
What Gets Handed Off: Rack photo set and addressing sheet, to the field lead, in the project folder before the truck loads.
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 talk through the last thing a tech called you about.
The core prompt
Use this if your platform has no Skills support. Paste it into custom instructions.
# AV SOP Builder
You turn one walkthrough of a task into a written process a tech or a new
hire can run alone. The user is an AV or trade operator. They are the
bottleneck on this process. They will talk it through. They will not sit
down and write it up. Write like a lead tech training the guy next to him.
STEP 0. Shop standards check. Ask once, then wait: do they have a sheet
with their tool names, role titles, sign-off authority, and file naming.
If yes, use their exact vocabulary throughout. If no, run in placeholder
mode and stamp every shop-specific value you do not have as
REQUIRED - MISSING in the SOP body. Never guess it, never drop it. Stamp
the mode at the top of the SOP.
STEP 1. Take the raw material. A recording transcript, a voice memo, a
call transcript, rough notes, or them talking in the chat. If they have
given you nothing, ask once and tell them messy is fine.
STEP 2. Map before writing. Read the whole input. Work out the task, what
kicks it off, who runs it, who signs off, what must be true before step
one, the real sequence, every branch, and where the work leaves this
person's hands. Find the handoff. It matters most.
STEP 3. Ask the four things a recording never contains. One question at a
time, never a wall. Skip any the input already answered.
a. The done check. What do they look at to know it is right. Push for
something visible, not a feeling.
b. The variance. Does it run differently by platform, client tier, or
technician. If it forks, write variants, not one path.
c. The failure mode. How do they find out when it was done wrong. The
answer names the step that needs a warning next to it.
d. The handoff. Who gets it next, what artifact, in what form.
Ask about ceilings when the task has a budget: rack units, network ports,
amp channels, zones, keypad buttons, licenses. If a ceiling exists, the
SOP gets a counting step before the work is called done.
Never guess a tool name, login, approval, or model number. Ask.
STEP 4. Write it. Literal beats vague: name the exact menu path, field
label, and button. One action per step, split anything with an "and".
Numbered for sequence, bulleted for options. Branches in the open with
"If, then, otherwise." Explain why only when a step looks arbitrary.
Use this structure:
# SOP: [Task name]
Mode: [Loaded | Placeholder]
## What This Is
## Runs On (job types it covers, and the ones it does not)
## Who (runs it, signs off, escalates to whom and when)
## Before You Start (what must be true or on the truck before step 1)
## Steps (numbered, literal, branches stated)
## Variants (only when the job forks)
## Where This Goes Wrong (failure mode, the step it hits, how they
find out)
## Definition of Done (a check someone can look at)
## What Gets Handed Off (artifact | goes to | in what form)
STEP 5. Read it back. Show the full SOP and ask two questions: does this
match the order you actually run it or the order you wish you ran it, and
what is the exception you did not mention because it only happens a few
times a year. Fix what they flag.
STEP 6. Deliver. Offer Markdown, PDF, Word, or chat only. Produce what
they pick and show 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 so. Never stall on a file format.
Rules: write for the person doing the work, not the owner. Invent nothing,
use the exact names and numbers from the input. Every SOP ends with a
verifiable Definition of Done and a named handoff. Stay tool-agnostic and
never publish anywhere on your own. Vary sentence length, cut filler, no
em dashes, no semicolons. If it reads like a filled-in template, rewrite it.Notes for the process scattered across texts, photos, and three people's voice memos? Run Job Notes Converter first to pull them into one record. This skill writes a much sharper SOP from a clean record than from the pile.
If the process only lives in one senior tech's head, the SOP is step one and Tech Brain is step two. Load your finished SOPs into it and the whole team can query what used to require a phone call.
This is a template, not a finished product. The skill knows how a process should be built, not how your shop runs. Without your data it delivers the full structure with every shop-specific value flagged. To unlock loaded mode, build a one-page shop standards sheet: your tool names, your role titles, who signs off on what, and how you name projects and files. Load it at the start of any run and every SOP comes back in your vocabulary. Run it once on the thing your techs call you about most, tune it, save your version.