Interviews you about how you do a task, then writes a clear step-by-step procedure anyone else could follow.
What it does
You have done the task two hundred times, so you cannot see it any more. Asked to write it down, you produce five lines that are all true and that nobody else can follow. Then the person covering for you asks eleven questions anyway.
With this skill active, the assistant interviews you instead of asking you to write. It walks the task one step at a time and asks the same three questions at every step: where exactly do you start, how do you know that worked, and what goes wrong here. Those questions surface the login you forgot, the check you do without noticing, and the exception that happens every January.
What comes back is a numbered procedure a stranger could follow: what they need before starting, one action per step, a check under each step, decision points written as branches with every path named, and a short list of what to do when it goes wrong.
You end up with a numbered procedure someone with no background could follow, including the checks and exceptions you never write down.
When to reach for it
Use it when you are handing work over, going on leave, training someone, or answering the same question every week because the process lives in one person's head.
Not the right tool for work that is mostly judgement rather than steps - it will capture the criteria and two examples and tell you honestly that the rest needs a person. For anything regulated or involving money, safety or personal data, treat the result as a first draft that still needs sign-off from whoever owns that risk.
---
name: sop-writer
description: Interviews someone about a task they do from memory, one step at a time, digging out the checks and exceptions they skip out of habit, then writes it up as a procedure a complete stranger could follow. Use for handing work over, documenting a process that lives in one person's head, or replacing the same question being asked every week.
---
# SOP Writer
You are the person asking the questions an expert stopped hearing years ago. The writing is the easy half. The interview is the skill.
An SOP - a standard operating procedure - is just a written guide for doing a task the same way every time.
## Why the interview matters more than the writing
Someone who has done a task two hundred times cannot see it any more. They skip the login, the check, the one file that lives somewhere odd, and the exception that happens every third month. They are not withholding those things. They genuinely do not experience them as steps.
Every gap in an SOP is a gap the expert could not see. Your questions are the only thing that finds them.
## Workflow
1. **Frame it.** Three questions before anything else: what is the task, what does finished and correct look like, and who will be following this?
2. **Set the floor.** What can you assume the reader already knows? Everything below that line has to be written out.
3. **Walk the task in order, one step at a time.** "What is the very first thing you do?" Then "what next?" Do not jump ahead and do not accept a summary.
4. **Ask the three quiet questions at every step.** Where exactly do you start, how do you know it worked, and what goes wrong here?
5. **Sweep for hidden knowledge** once the walk is complete: access, approvals, timing, exceptions, and who to ask when stuck.
6. **Write it up** as numbered steps, one action each.
7. **Run the cold read.** Read your own draft as someone who has never done this. Every point where you would hesitate is a missing step. Go back and ask.
8. **Add the header block** - purpose, owner, who does it, how often, last checked - and hand it over.
Copy this checklist into your working notes and tick it as you go:
```text
SOP checklist
[ ] Task, "done" definition, and reader established
[ ] Assumed-knowledge floor agreed
[ ] Task walked step by step, in order, not summarised
[ ] Three quiet questions asked at every step
[ ] Hidden knowledge swept: access, approvals, timing, exceptions, who to ask
[ ] Decision points written as branches, not as prose
[ ] One action per step, no step containing "and"
[ ] Every step has a check where one exists
[ ] Cold read done, hesitations turned into questions
[ ] Header block: purpose, owner, frequency, last checked
```
## The three quiet questions
Ask all three at every step. They are short, and they are where the real content comes from.
- **"Where exactly do you start?"** Which screen, which folder, which tab, logged in as whom. Experts start from a state they set up without noticing.
- **"How do you know that worked?"** The check. This is the single most-skipped element in written procedures and the one that turns a click-list into something a stranger can trust.
- **"What goes wrong here?"** The exceptions. Ask even when they say nothing does, and follow with "when was the last time it did?"
## The hidden knowledge sweep
Run this after the walk-through, not during it. Each question reliably finds something the expert did not think to mention.
- What access do you need, and who grants it? Logins, permissions, keys, physical access.
- Does anyone have to approve anything, and what happens while you wait?
- Does timing matter? Time of day, day of week, before or after some other process runs.
- What do you do differently at month end, quarter end, or in a busy period?
- What do you check before you start that would waste an hour if it were wrong?
- Who do you ask when you are stuck, and about what?
- Is there anything you do that is not really part of the task but everything breaks if you skip it?
That last question is the best one in the set. It is where the undocumented habit lives.
## Writing the steps
- One action per step. If a step contains "and", it is two steps.
- Start each step with a verb: open, click, check, enter, save, send.
- Name things exactly as they appear on screen, in quotation marks where it helps.
- Put the check in its own line under the step it belongs to.
- Never write "as usual", "the normal way", or "you know the one". Those phrases mean the interview is not finished.
- Where a step depends on a choice, write it as a branch with both paths, not as a sentence with "unless" in it.
## Decision points
Prose hides branches. "Approve it unless the amount is over the limit, in which case send it up" reads fine and gets followed wrongly. Write it as:
```text
5. Check the amount on the request.
- Under £500: approve it yourself. Go to step 6.
- £500 or over: send it to the finance lead for approval. Wait for their reply, then go to step 6.
- No amount shown: return it to the sender and ask for one. Stop here.
```
Every branch ends by naming the next step or by saying stop. A branch that trails off is where people improvise.
## Output shape
```text
Title
Purpose: one line on why this task exists.
Who does this / how often: one line.
Owner: who keeps this document correct.
Last checked: date.
Before you start
- access, logins, files, tools, information needed
Steps
1. One action.
Check: how you know it worked.
2. ...
How to know the whole thing worked
What a correct finished result looks like.
If something goes wrong
The two or three common problems, each with what to do.
Who to ask
Name or role, and for what.
```
## Example
**The task:** send the weekly sales report.
**What the user said first**
> I open the dashboard, filter to last week, export it as a PDF and email it to the leadership list. Takes five minutes.
**The interview**
> **Where exactly do you start?** - "The sales dashboard." Which one? There are two, and one of them is the old one that still loads. Named it.
> **How do you get in?** - Single sign-on, but you need the Reporting role, which the systems team grants. New person would stop dead here.
> **Filter to last week - how exactly?** - The date preset says "Last 7 days", which she never uses because it includes today. She sets the dates manually, Monday to Sunday.
> **How do you know the export worked?** - "The total on the PDF should match the total on screen." She checks this every time and had never mentioned it. It is the most important line in the whole document.
> **What goes wrong?** - If the export runs before 9am on Monday, the weekend transactions have not synced and the total is short. She learned this once and now always waits.
> **Anything you do that is not really part of the task?** - She reads the top three accounts before sending, and adds a sentence if anything looks odd. Nobody asked her to. It is the reason leadership trusts the report.
**The result**
> **Weekly sales report**
> **Purpose:** gives leadership last week's sales figures every Monday.
> **Who does this / how often:** the sales operations coordinator, every Monday morning.
> **Owner:** sales operations. **Last checked:** 3 June.
>
> **Before you start**
> - Access to the Sales Dashboard (the one at the internal reporting address, not the legacy dashboard) with the "Reporting" role. The systems team grants this; allow a day.
> - Access to the "Leadership" email group.
> - Do not start before 9:00 on Monday. Weekend transactions finish syncing at 08:30 and an earlier export will under-report.
>
> **Steps**
> 1. Open the Sales Dashboard and sign in.
> Check: the header reads "Sales Dashboard" with this week's date. If it says "Legacy", you are in the old one - use the address in "Before you start".
> 2. Set the date range manually to last Monday through last Sunday.
> Check: both dates are visible above the chart. Do not use the "Last 7 days" preset - it includes today and will change the totals.
> 3. Write down the total shown at the top right.
> 4. Click "Export", then choose "PDF".
> 5. Open the PDF and compare its total to the number from step 3.
> Check: the two totals match exactly. If they do not, the export ran mid-sync. Wait ten minutes and repeat from step 2.
> 6. Look at the top three accounts in the report.
> - Anything unusual - a large refund, a missing regular account, an unexpected spike: add one sentence to the email saying what you noticed.
> - Nothing unusual: continue.
> 7. Email the PDF to the Leadership group with the subject "Weekly sales - week ending [date]".
>
> **How to know the whole thing worked:** the leadership group has the PDF before 10:00 on Monday, and its total matches the dashboard.
>
> **If something goes wrong**
> - *Totals do not match:* the export ran during a sync. Wait ten minutes, repeat from step 2.
> - *Dashboard will not load:* check with the systems team that you have the Reporting role before assuming it is broken.
> - *A regular account is missing entirely:* do not send. Ask sales operations first - it usually means a data issue, not a bad week.
>
> **Who to ask:** systems team for access, sales operations for anything about the numbers.
The five-minute task became seven steps with four checks. Nothing was invented: every addition came from an answer to one of the three quiet questions.
## Rules
- Never guess a step. If they skipped something, ask.
- One action per step.
- Write for someone with no background. Explain every tool, button and term the first time.
- Include the checks. A procedure without them tells someone what to click, not whether it worked.
- Capture the "obvious" parts. Those are what new people get stuck on.
- Use the exact words on screen, not paraphrases.
- Record the exceptions where they happen, not in a lump at the end.
- Keep it plain. No jargon without a one-line explanation next to it.
## Edge cases
- **They dump the whole thing at once** instead of answering step by step. Turn the dump into a numbered draft, then interview the gaps. Show them the draft; people correct a document far more readily than they answer an open question.
- **The task changes depending on circumstances.** Write the common path in full, then branch. If there are more than about three branches, it is more than one procedure.
- **The expert disagrees with how it is officially done.** Document what they actually do, and note the difference. The gap is usually either a shortcut worth adopting or a control worth reinstating, and hiding it helps nobody.
- **Nobody remembers why a step exists.** Keep it, mark it "reason unknown, check before removing". Steps like this often turn out to be the only thing preventing an old problem.
- **The task needs judgement rather than steps.** Some parts cannot be proceduralised. Write the criteria the expert uses and two worked examples, and say plainly that this step needs a person.
- **It is dangerous or regulated** - anything with money, safety, personal data or legal filing. Write it, then mark it as needing sign-off from whoever owns that risk. Do not present an interviewed SOP as compliant on its own.
- **The interview reveals the process is broken.** Say so once, write the SOP for the process as it is, and list the fixes separately. Documenting and redesigning at the same time produces neither.
- **They only have twenty minutes.** Walk the happy path only, mark the document "first pass, exceptions not yet captured", and book the second session.
## Files
- `references/examples.md` - three procedures worked end to end, including a full interview transcript, a branchy refund process, and the rescue of an existing SOP nobody could follow. Read it to see which questions produce the missing content.
- `references/template.md` - the blank SOP skeleton, the interview question bank organised by stage, step-writing rules with good and bad versions side by side, and a handover check for testing the finished document on a real person. Read it before starting an interview.
references/examples.md
# Worked procedures
Three tasks documented. The first shows the interview in full, because the questions are the part worth copying.
## Contents
- [Example 1: the interview in full](#example-1-the-interview-in-full)
- [Example 2: a process with real branches](#example-2-a-process-with-real-branches)
- [Example 3: rescuing an SOP nobody could follow](#example-3-rescuing-an-sop-nobody-could-follow)
- [What the three have in common](#what-the-three-have-in-common)
---
## Example 1: the interview in full
**The task:** onboarding a new client at a small accountancy practice. The practice manager has done it about eighty times and is going on leave for three months.
### Framing
> **What is the task, and what does finished look like?**
> "Getting a new client set up. Done is when they are in the system, we have their paperwork, and they have had the welcome call."
>
> **Who will follow this?**
> "Whoever covers for me. Probably Josh, who has been here five months."
>
> **What can we assume Josh knows?**
> "He knows the practice software and he has sat in on a welcome call. He has never done the compliance checks and he does not have access to the client folder structure."
That last answer set the floor. Everything about the compliance checks and the folder structure has to be written out in full; the practice software can be referred to by name.
### The walk-through
> **What is the very first thing you do?**
> "Set them up in the practice software."
>
> **Before that - how do you know a new client is coming?**
> "Oh. The partner sends me an email saying we have won them." *(A step she does not experience as a step. It is now step 1, and it names what that email must contain.)*
>
> **What if the email is missing something?**
> "It usually is. I go back and ask for the entity type and the year end, because I cannot set them up without those."
>
> **Setting them up in the software - where exactly do you start?**
> "New client, top right. But first I search the name, because sometimes they were a client years ago and there is an old record."
>
> **How do you know the setup worked?**
> "The client reference generates. If it does not, something in the required fields is wrong."
>
> **What goes wrong here?**
> "If you pick the wrong entity type you cannot change it later without an admin. That is the one that hurts."
>
> **Then what?**
> "Compliance checks. Identity documents and the risk assessment."
>
> **Walk me through that as if I have never done it.**
> "You collect photo identification and proof of address, run them through the verification tool, and save the result in the client folder."
>
> **Which folder, exactly?**
> "The client folder, under Compliance. It has to be that one, because that is where the audit looks." *(Josh has no access to this. It became a line in "Before you start".)*
>
> **How do you know that step is complete?**
> "The verification tool gives you a pass, refer or fail. Pass means carry on. Refer means it goes to a partner."
>
> **What happens while you wait for a partner on a refer?**
> "Nothing else moves. You cannot do the engagement letter until compliance clears." *(A dependency, invisible in her original three-sentence summary.)*
>
> **What do you do differently in busy periods?**
> "In January I chase the paperwork twice a week instead of once, because January onboarding always stalls on documents."
>
> **Is there anything you do that is not really part of the task, but things break if you skip it?**
> "I put a note in the partner's calendar for the welcome call rather than emailing them about it. If I email, it gets missed."
### The finished procedure, abbreviated
> **Onboarding a new client**
> **Purpose:** get a won client from the partner's email to a completed welcome call, with compliance done correctly.
> **Who does this / how often:** practice manager, roughly twice a month.
> **Owner:** practice manager. **Last checked:** 12 May.
>
> **Before you start**
> - Access to the practice software with client-creation rights.
> - Write access to the client folder structure, including the Compliance folder. Request from the systems partner; takes a day or two.
> - Access to the identity verification tool.
>
> **Steps**
> 1. Confirm the partner's "we have won them" email contains: legal name, entity type, year end, main contact and their email.
> - Anything missing: reply and ask before continuing. You cannot create the record without entity type and year end.
> 2. Search the practice software for the client name before creating anything.
> - Existing record found: reactivate it, do not create a second one. Continue at step 4.
> - No record: continue to step 3.
> 3. Create the client. Take particular care with entity type - it cannot be changed later without an administrator.
> Check: a client reference has generated. If not, a required field is wrong.
> 4. Collect photo identification and proof of address from the main contact.
> 5. Run both through the verification tool and save the result to the client folder, under Compliance. It must be that folder; the annual audit looks there.
> - Pass: continue to step 6.
> - Refer: send it to a partner and stop here. Nothing else can proceed until compliance clears.
> - Fail: send it to a partner immediately. Do not contact the client.
> 6. Send the engagement letter.
> 7. Put the welcome call in the partner's calendar directly. Do not email them to arrange it - calendar entries get seen, emails do not.
>
> **If something goes wrong**
> - *Entity type entered incorrectly:* stop and ask an administrator. Do not create a second record.
> - *Documents not arriving:* chase weekly, and twice weekly in January, when onboarding routinely stalls here.
>
> **Who to ask:** systems partner for access, any partner for a compliance refer.
**Why it is shaped this way:** three of the seven steps came from questions rather than from the original description. The partner's email, the duplicate-record search and the calendar habit were all invisible to someone who had done this eighty times.
---
## Example 2: a process with real branches
**The task:** handling a customer refund request at an online retailer.
The first draft the user wrote themselves read: "Check if it is within 30 days, refund it unless it is used or was on sale, and if it is over £200 get a manager." Three conditions in one sentence, which is why the team was applying it four different ways.
### The finished procedure, steps only
> 1. Open the order in the admin system and note the order date, the amount and the item condition reported by the customer.
> 2. Work out how many days have passed since delivery, not since the order date.
> - 30 days or fewer: continue to step 3.
> - 31 to 60 days: continue to step 3, but the outcome will be a credit note rather than a refund. Note this now so you can tell the customer once, at step 6.
> - Over 60 days: no refund or credit. Go to step 7.
> 3. Check whether the item was bought at a discount of 30% or more.
> - Yes: credit note only, whatever the date. Continue to step 4.
> - No: continue to step 4.
> 4. Check the reported condition.
> - Unopened: continue to step 5.
> - Opened but unused: continue to step 5.
> - Used or damaged by the customer: this needs a manager. Send it to the duty manager with photographs and stop here.
> 5. Check the amount.
> - Under £200: you can approve it. Continue to step 6.
> - £200 or over: send to the duty manager for approval, then continue to step 6 once approved.
> 6. Process the refund or credit note and email the customer. Tell them which one they are getting and why, in one sentence. Do not list the policy.
> Check: the order shows "Refunded" or "Credit issued", and the customer email has sent.
> 7. If nothing can be offered, do not send a policy quotation. Send it to the duty manager with a one-line summary. Refusals go out from managers, not from the service team.
**Why it is shaped this way:** each condition became its own step with every path named, and every path ends by naming the next step or by stopping. The original sentence had a gap nobody had noticed - what happens between 31 and 60 days - which only became visible when the conditions were separated. Step 7 also moves refusals to a manager, which came out of the interview question "what goes wrong here?" and the answer "people quote the policy at customers and it escalates".
---
## Example 3: rescuing an SOP nobody could follow
**The situation:** an existing one-page document for the monthly supplier payment run. Three people have been trained on it and all three still ask questions.
### What the original said
> "Run the payment report, check it against the invoices, get approval, upload to the bank, confirm."
Five steps, all of them true, none of them followable.
### What the interview found
Asking the three quiet questions of each line produced eleven questions the document could not answer. The most damaging:
- **"Run the payment report" - from where?** Two systems produce something with that name. One is the correct one; the other looks right and is missing anything entered in the last 48 hours.
- **"Check it against the invoices" - check what, exactly?** Three things: that every line has an invoice, that the totals match, and that no supplier appears twice. Nobody had written this down and each of the three trainees checked a different subset.
- **"Get approval" - from whom?** Whoever is available, unless it is over £10,000, when it must be a director. The threshold existed only in the original person's head.
- **"Upload to the bank" - what happens if it fails halfway?** It has happened twice. The recovery is specific, and doing the obvious thing instead creates duplicate payments.
- **"Confirm" - to whom, and what?** Reply to the approver with the bank reference, then file the report. Neither step was written.
### The change
Five lines became fourteen steps with six checks and one branch. The document is longer, which was the whole problem: it was short because it was written by someone who did not need it.
**Why it is shaped this way:** rescuing an existing document is the same interview, run against the document rather than against the task. Read each line aloud and ask the three quiet questions. Every line that cannot answer them is a line that has been costing someone a question every month.
---
## What the three have in common
- The steps the expert did not know they were taking came out of the same few questions, asked at every step, not out of the expert trying harder to remember.
- Every branch is written as a branch, with each path ending in a next step or a stop.
- Checks sit under the step they belong to, and each one names what to do if the check fails.
- Access and permissions ended up in "Before you start" in all three, because the successor never has them and this is where handovers usually stall on day one.
- The finished documents are longer than the expert's description of them, every time. That difference is the work.
references/template.md
# Template and question bank
The skeleton to fill, the questions that fill it, and the test that tells you it worked.
## Contents
- [The SOP skeleton](#the-sop-skeleton)
- [Interview questions by stage](#interview-questions-by-stage)
- [Step writing: weak against usable](#step-writing-weak-against-usable)
- [Phrases that mean the interview is not finished](#phrases-that-mean-the-interview-is-not-finished)
- [The cold read](#the-cold-read)
- [The handover test](#the-handover-test)
- [Keeping it correct](#keeping-it-correct)
---
## The SOP skeleton
```text
<TASK NAME>
Purpose: <why this task exists, one line>
Who does this / how often: <role, frequency>
Owner: <who keeps this document correct>
Last checked: <date>
BEFORE YOU START
- Access: <systems, logins, permissions, and who grants each>
- Have ready: <files, information, physical items>
- Timing: <anything about when this can or cannot be done>
STEPS
1. <Verb> <one action>.
Check: <how you know it worked, and what to do if it did not>
2. <Verb> <one action>.
- <Condition A>: <what to do>. Go to step N.
- <Condition B>: <what to do>. Stop here / go to step M.
3. ...
HOW TO KNOW THE WHOLE THING WORKED
<what a correct finished result looks like, in terms someone could verify>
IF SOMETHING GOES WRONG
- <common problem>: <what to do>
- <common problem>: <what to do>
WHO TO ASK
- <name or role> for <what>
```
## Interview questions by stage
### Framing, before any steps
- What is this task called by the people who do it?
- What does finished and correct look like?
- Who will follow this, and what do they already know?
- How often is it done, and by whom now?
- What happens if it is done wrong? This sets how much detail the checks need.
### At every single step
- Where exactly do you start? Which screen, folder, tab, logged in as whom.
- How do you know that worked before moving on?
- What goes wrong here? And when did it last go wrong?
### The hidden knowledge sweep, after the walk-through
- What access do you need, and who grants it?
- Does anyone have to approve anything? What do you do while you wait?
- Does timing matter - time of day, day of week, before or after another process?
- What changes at month end, quarter end, or in your busy season?
- What do you check before starting that would waste an hour if it were wrong?
- Who do you ask when you are stuck, and about what?
- Is there anything you do that is not really part of the task, but everything breaks if you skip it?
- What would a new person get wrong on their first attempt?
- Which part do you dislike most? Dread usually marks the fiddliest, least documented part.
### Closing
- If you were away tomorrow and this had to happen, what would you worry about?
- What is in your head that is not in this document?
## Step writing: weak against usable
| Weak | Usable |
|---|---|
| "Log into the system" | "Open the Sales Dashboard at [address] and sign in with your work account" |
| "Check the numbers match" | "Compare the PDF total to the figure you noted in step 3. They must match exactly" |
| "Export and send it" | Two steps: "Click Export, choose PDF" then "Email it to the Leadership group" |
| "Approve if it is small" | "Under £500: approve it yourself. £500 or over: send to the finance lead" |
| "File it in the usual place" | "Save it to the client folder, under Compliance" |
| "Wait for it to finish" | "Wait until the status reads Complete. Typically two minutes; if over ten, see 'If something goes wrong'" |
| "Handle any errors" | Name the two errors that actually occur and what to do for each |
## Phrases that mean the interview is not finished
Every one of these is a signal to ask another question, not to write it down.
- "As usual" / "the normal way"
- "You know the one"
- "It is obvious once you see it"
- "Just check it looks right"
- "Someone will tell you if it is wrong"
- "It depends"
- "Usually" - ask what happens the rest of the time
- "Make sure everything is correct" - correct how, checked against what
- "Then it is basically done" - the word "basically" is hiding a step
## The cold read
Before handing the document over, read it as someone who has never done the task. At every point where you would pause, hesitate, or open a second tab to work something out, mark it. Each mark is a missing step or a missing check, and each one goes back to the expert as a question.
Do this on the document alone, without the interview notes beside you. The notes will fill gaps in your head that the reader will not have.
## The handover test
The only real test is a person. Give the document to someone who has never done the task and ask them to follow it while the expert watches without speaking.
- Every question they ask out loud is a missing step.
- Every time the expert has to physically stop themselves from intervening, that is a gap.
- Every place they hesitate for more than a few seconds needs a check or a clearer instruction.
Fix what the test finds, then mark the document as tested and dated. An untested SOP is a draft.
## Keeping it correct
- Name an owner. A document with no owner is out of date within a year.
- Put the last-checked date at the top where it is visible, not at the bottom.
- Review when the tool changes, when the person changes, and once a year regardless.
- When someone finds a gap, fix the document that day. The gap will be found again otherwise, by someone with less patience.
Install it
Claude Code (this project)
Unzip the download into .claude/skills/. The folder is already named right.
Claude Code (every project)
Unzip into ~/.claude/skills/ to use it everywhere.
claude.ai
Upload the zip under Settings, then Capabilities, then Skills (paid plans).
How to call it
Just describe the task. The description line inside the skill does the matching. Or call it directly:
/sop-writerhelp me write down how I do thisdocument this process so someone else can do itI'm going on leave and need to hand this overwrite a step by step guide for this tasknobody can follow our existing instructions
Works beyond Claude
Skills use the open Agent Skills format. The exact same folder works in OpenAI Codex, Gemini CLI, Cursor, GitHub Copilot and other tools that read the format.
Using a plain chat app? Paste SKILL.md into ChatGPT or Gemini as instructions. You lose auto-triggering, but the method still works.
