SOPs as Skills

By the end of this install, someone on your team runs one of your processes — the one that currently queues behind you — and the output comes back the way you would have done it. Not because they memorized your standards, but because your standards are now a skill file: the trigger, the steps, the decision rules you actually use, and the quality bar, written down once and run by anyone. You watch them run it end to end without you in the room. That's the demo, and it's also the delegation unlock this whole track has been building toward.

You'll also leave with the pattern, because the second SOP takes half the time of the first.

Prerequisites

• Install 0.5 — The Firewall: you'll anonymize the worked example if you're on Lane A.
• Install 4 — The Document Engine: you've built a skill before; this uses the same muscle on a process instead of a format.
• One recurring process that currently bottlenecks on you — vendor review, discount approval, client onboarding, incident triage.
• One team member willing to run the first test.
• 20 minutes.

Build steps

1. Pick the right SOP. Not your most complex process — your most repeated judgment. Paste this:

   Here are five recurring processes my team runs where I'm currently the bottleneck: [list them, one line each]. Score each 1–5 on: how often it runs, how much of MY specific judgment it needs, how clearly its inputs and outputs can be defined, and the pain caused when it's done wrong. Recommend the single best candidate to turn into a repeatable skill first, and explain why in two sentences.
   

2. Run the extraction interview. This is where the real value transfers — the rules in your head, not the ones in the wiki. Paste this and answer honestly:

   You are going to turn one of my team's processes into a written skill that a colleague can run with Claude, without me in the room. Interview me one question at a time until you can write it. Cover: the trigger (what starts this process), the inputs (what must be in hand before starting), the steps in order, the decision points — and for each one, the rule I actually use to decide, including exceptions, the quality bar (how I judge the output is good enough to go out), and the failure modes (the mistakes people make and how I catch them). Push back when my answers are vague — "it depends" is not an answer; ask "depends on what?"
   

   Expect 10–15 questions. The uncomfortable ones ("what exactly makes you reject a draft?") are the ones doing the work.

3. Generate the skill file. When the interview ends, paste this:

   Now write this up as a skill file using this structure: Purpose (one line), When to run this, Inputs required, Steps, Decision rules, Quality checklist, "Escalate to me when", and one fully worked example. Write it in second person, addressed to the team member running it. Every decision rule must be concrete enough that two different people would make the same call. If any rule is still ambiguous, ask me before writing it.
   

   Save the output as [process-name]-skill.md. The download below is the empty structure, if you'd rather fill it by hand.

4. Test it against last week. Take the most recent real instance of this process and have Claude run the skill on it. Compare the output to what actually happened. Where they differ, fix the rule, not the output — edits go into the skill file so it's right by default next time.

5. Hand it over. Send the skill file to your team member with one instruction: run the next real instance through Claude using this skill, and bring me the output — not questions about the process. Review their first two outputs against the quality checklist. After that, you review results, not process. That sentence is the hours-back.

6. Bank the pattern. Steps 1–5 are the pattern: pick, extract, generate, test, hand over. Put a 20-minute slot in your calendar monthly and convert one more. Keep a one-line register of skills shipped — it becomes Exhibit A in Install 9.

The Two-Lane note

Lane A (no company workspace yet): the skill file itself is safe to build on a personal account if you keep it generic — role names instead of people ("the account lead", not "Sarah"), Firewall-scrubbed numbers in the worked example, no client names, no contract terms. Your team members run it on their own personal accounts with training switched off (their Install 0), pasting only anonymized inputs. It works, and every scrubbing step is friction you'll quote in Install 9.

Lane B (company Claude Team/Enterprise): put the skill in a shared Project so the whole team runs the same current version against real data — real client names, real numbers, live connectors — under the contractual no-training terms. Updates to the skill propagate instantly instead of via email attachments. This is the difference between a document people have and a system people use.

Component shipped

You now have one team skill — your judgment on one process, packaged and runnable without you — plus the five-step pattern for converting the next one. Tomorrow morning, when that process lands in your inbox, you forward it with one line: "Run it through the skill, send me the output."