What changes when an SOP becomes a skill?
Procedures often assume knowledge that experienced staff carry in their heads. Ask the person who does the work to explain exceptions and judgment calls. Those details are often more useful than copying the existing document unchanged.
| 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 |
First describe when the procedure applies. Then write the steps, decision rules and approval points. Add templates after the process is clear.
Collect the evidence before you write a line
Review completed examples alongside the written procedure. Include cases where something was missing or went wrong. Mark which references are current and authoritative so the agent does not treat an old template as the latest rule.
- 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?
For each decision, explain what information determines the next step and when to ask a person. Include an example of a wrong answer. If the decision needs human judgment, name who makes it.
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.
Describe when the skill should be used
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
---Also describe nearby tasks it should not handle. A payment-reminder procedure, for example, should not automatically decide a disputed refund.
How do you prove the skill works?
Create test cases before relying on the skill. Include routine examples, missing information and exceptions. Run them with the actual model and tools your team will use, because changing the setup can change the result.
| 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 |
Keep a version history and review date
Record the version, changes, known limits and how to restore an earlier copy. Set a review date and update the skill whenever the underlying business procedure changes.
How long does converting one SOP actually take?
Timing depends on how clear the procedure is and how many exceptions it contains. Allow for talking with the person who does the work, writing the instructions and testing ordinary and unusual cases.
Should the agent handle the whole process or part of it?
Start with a repeatable part whose result is easy to check, such as drafting, sorting or formatting. Keep consequential decisions under the appropriate person’s approval.
What if the SOP is out of date or was never written down?
Document the process with the person responsible for it. Review completed examples and agree on the decision rules before using them as agent instructions.
Test your SOP as a repeatable workflow
Choose a procedure with accepted examples and clear ownership. We can help map its inputs, exceptions, output format, and approval points, then check the result against the work your team already accepts.