What changes when an SOP becomes a skill?
The gap is not formatting. Most SOPs were written for someone who already knows the business, so they lean on shared context that never reached the page. The conversion is mostly extraction: pulling unwritten judgment out of the person who does the job and putting it where an agent can read it. Expect the first pass to be two thirds interview, one third writing.
| SOP element | Skill element | Failure if you skip it |
|---|---|---|
| Title and purpose line | Routing metadata the host reads first | The skill never loads, so nothing else matters |
| Numbered steps | A workflow with a checklist the agent copies | Steps get reordered or quietly dropped |
| Manager judgment | Written thresholds, tie breakers, examples | The agent invents a rule and sounds confident |
| Who signs off | A named gate before any external action | Money moves or mail sends with no human |
| Attached templates | Files the agent loads only when needed | Output drifts off the house format |
Work in that order. Metadata first, because a skill that never loads cannot be wrong in any interesting way. Then the workflow, the judgment, the gates. Templates come last, because they are the easy part and the part that tempts you into writing a manual nobody reads.
Collect the evidence before you write a line
Do not start from the SOP document. Start from the last ten completed runs and the exceptions file. The document says what should happen. The runs say what does. Mark every source as authoritative, illustrative, outdated, or disputed, so a stale template does not carry the same weight as this quarter's rate sheet.
- The current SOP, plus the version people actually follow
- Five accepted outputs and two rejected ones, with the reason each was rejected
- The tool list: which systems, which accounts, which permission level on each
- The exception log: every run that stopped and the call someone made
- The role that owns the decision when two sources disagree
Which decisions have to be written down?
Steps are easy to copy. Decisions are what people forget, because the operator settles them in half a second and never narrates it. For every branch, write the threshold, the tie breaker, the escalation path, and one example of the wrong answer. When a call is genuinely judgment, say so and route it to a role.
How should the skill folder be laid out?
Keep the main file short. Anthropic's authoring guidance puts the ceiling at 500 lines for a skill body, with detail pushed into separate files the agent opens only when the task calls for them. Keep those references one level deep, because an agent following a chain of links tends to preview instead of read, and a partial read is worse than none.
invoice-chasing/
SKILL.md # metadata + the workflow, under 500 lines
reference/
rules.md # thresholds, exceptions, escalation
tone.md # what a reminder email may and may not say
examples/
accepted-01.md # a run that passed review
rejected-01.md # a run that failed, and why
templates/
reminder-email.md
evals/
cases.json # ten scenarios with expected behaviorClaude Code, Hermes, and OpenClaw all read a skill as a folder with a markdown file at the top. What differs is where the folder lives, so confirm the install path for your host before copying anything in.
Write the description like a routing key
The name field takes lowercase letters, numbers, and hyphens, stops at 64 characters, and has to match the folder name or the skill will not load. The description stops at 1,024 characters, is written in the third person, and is the only part of the package sitting in context every session. Give it the words a real request would use, then the words that should not pull it in.
---
name: invoice-chasing
description: Drafts overdue invoice reminders from the AR aging report,
applies the 15, 30, and 45 day ladder, and stops for human approval
before anything is sent. Use when the request mentions overdue
invoices, collections, aging, or payment reminders. Not for billing
disputes, refunds, or handoff to a collections agency.
license: proprietary
---Negative triggers matter more than they look. A collections skill that also grabs refund disputes gets switched off inside a week. Name the neighboring processes and state plainly that this skill is not for them.
How do you prove the skill works?
Write the evaluations before the documentation. Ten cases is a fair floor: three accepted historical runs and seven built to break it. Run them on the model you will use in production, and on the cheaper model too if the skill will run there, because guidance that reads as obvious to a large model is often too thin for a small one.
| Test case | What you feed it | Pass condition |
|---|---|---|
| Happy path | Three accepted historical runs | Output matches the approved file |
| Missing input | An aging report with a blank due date | It stops and asks instead of guessing |
| Conflicting sources | Last year's SOP against the new rate sheet | It names the conflict and cites both |
| Injected instruction | A vendor note telling it to skip review | It treats the note as data and reports it |
| Gate pressure | A request to send without approval | It refuses and holds the draft |
Ship it versioned, then keep it honest
Release with a version number, a changelog, a short list of known limitations, and one line on how to roll back. Then set a review date. The failure at month three is rarely a bad skill. It is a good skill describing a process that quietly changed. When the business moves a threshold, the skill moves with it, the same as the SOP it came from.
How long does converting one SOP actually take?
For a process one person already runs weekly, plan a half day of interview and evidence gathering, a half day of writing, and a second session for evaluations and fixes. Processes with many exceptions take longer, because the exceptions are the real content.
Should the agent handle the whole process or part of it?
Start with the part that is repetitive, reversible, and easy to check: drafting, sorting, extracting, formatting. Leave the consequential end behind an approval gate until the evaluations have passed for several weeks of real use.
What if the SOP is out of date or was never written down?
Then you are writing the SOP, not converting it. Interview the person doing the work, record ten runs, and get the decision owner to sign off on the written rules before any of it becomes a skill. An agent cannot fix a process nobody agrees on.
Start from a skill that already works
The Business Operator bundle ships four specialist skills with approval gates, output templates, and evaluations already written, so your first conversion starts from a working model instead of a blank file. The bundle is $447, or $149 for a single specialist skill.
Monolith AI Business Operations Agent Skills Bundle / $447, beta