sop_writing v1.0.0

---

name: sop_writing description: "Write standard operating procedures that a person or an agent can follow cold: scope and ownership, task decomposition, numbered steps with named actors, decision points, acceptance criteria, deviation handling, records, and a controlled review cycle. Use when someone asks for an SOP, a procedure document, work instructions for recurring work, or a rewrite of a vague procedure. For incident response use a runbook skill instead; for analysing a process use business process mapping."

---

SOP Writing

Purpose

An SOP is a controlled document for work that repeats. It fixes one approved way to do a task so that two competent people, or two agent runs, produce the same result. This skill covers the full job: deciding whether a task needs an SOP, breaking the work into steps, writing those steps so they can be followed without guessing, testing the draft on a real performer, and keeping the document current after it ships.

Know the neighbouring document types and pick the right one:

| Document | Job | Test | | --- | --- | --- | | Policy | States a rule and who it binds | Can you audit against it? | | SOP | Describes a recurring process end to end: who, what order, what counts as done | Can a trained newcomer run it start to finish? | | Work instruction | Covers one task inside an SOP in fine detail | Can someone do that single task from it alone? | | Runbook | Guides a response to a known failure or alert | Can a tired operator act on it at 3am? | | Checklist | Confirms steps were done, in order | Can each line be ticked yes or no? |

If the work happens once, write a plan. If it happens in response to an incident, write a runbook. If it repeats on a schedule or on demand, write an SOP.

Workflow

1. Frame the job before writing

Collect these facts first. Interview the person who does the work now, and watch one real run if you can. Notes from memory produce SOPs that describe the work people wish they did.

• Trigger: what starts this process (a request arrives, a date hits, an alert fires).
• End state: the concrete thing that exists when the work is done.
• Performer: the role that does it, plus the skills or access that role needs.
• Owner: the role accountable for the document staying correct.
• Frequency and volume: how often it runs, and how many items a run handles.
• Cost of error: what breaks, who notices, and how hard it is to undo.
• Inputs and tools: systems, files, materials, and permissions the performer needs at the start.
• Exceptions already known: the cases where the normal path fails today.

Decide the boundary. An SOP that covers three processes is three SOPs with cross references. One process, one document, one owner.

2. Decompose the task

Break the process into phases, then into steps. Work down until each step passes three tests:

1. One actor. If a step names two roles, split it at the handoff and say what passes across.
2. One action. One verb, one object. "Check the invoice total against the purchase order" is a step. "Check and file the paperwork" is two.
3. One checkable result. After the step, something is true that a reviewer can verify: a value matches, a file exists, a status changed.

Group steps into phases of roughly five to nine steps. Name each phase for its outcome, for example "Verify the request" rather than "Step 1 part 2". Mark handoffs, waits, and approvals as their own steps, since that is where real processes stall.

3. Draft with the standard structure

Use assets/sop-template.md. Every SOP carries these sections, in this order:

1. Header block: title, document ID, version, owner, author, approver, effective date, next review date, supersedes.
2. Purpose: one or two sentences on the outcome the SOP protects.
3. Scope: where it applies, where it does not, and what sits outside the boundary.
4. Roles and responsibilities: who performs, who approves, who gets notified.
5. Definitions: terms and abbreviations a new performer would not know.
6. Prerequisites: access, tools, inputs, and conditions that must hold before step 1.
7. Safety and compliance notes: hazards, legal or policy constraints, placed here and repeated at the step where they bite.
8. Procedure: phases and numbered steps.
9. Decision points: the branches, written where they occur in the flow.
10. Acceptance criteria: how anyone can tell the finished work is right.
11. Exceptions and deviations: what to do when a step cannot be completed as written.
12. Records: what evidence each run leaves, where it is stored, and how long it is kept.
13. References: the policies, sibling SOPs, and source documents this one depends on.
14. Revision history: version, date, author, what changed and why.

4. Write steps that survive contact with a real performer

Each step follows the same shape: actor, imperative verb, object, and the limit or standard that makes it checkable.

• Weak: "Ensure the form is filled in correctly."
• Usable: "Finance reviewer: compare the total on form F-12 with the purchase order. If the totals differ by more than 0.01, stop and follow the exceptions section."

Rules for step text:

• Start with a verb in the imperative: compare, enter, send, wait, record, escalate.
• Name the actor when it changes. Inside a phase owned by one role, name it once at the phase heading.
• Put the condition before the action: "If the account is frozen, stop" reads better under pressure than the reverse.
• Replace vague words with numbers or named states. Ban "appropriate", "timely", "as soon as possible", "properly", "regularly", and "etc." from step text unless the sentence also gives the value.
• Give exact locations: system name, menu path, field name, file path, template name. "In the system" is not a location.
• State the expected result of any step where the performer could plausibly go wrong: "The status changes to Approved within one minute."
• Keep one idea per sentence. Short sentences survive stress and translation.
• Use "must" for a hard requirement, "should" for a strong default, and "may" for a real choice. Never use "shall".

5. Write decision points as branches, not prose

Every fork gets the same treatment: the condition, how the performer tests it, and where each answer leads.

Decision D2: Is the request total over 5,000?
- Test: read the Total field on the approved request form.
- Yes: route to the budget holder for approval (step 4.3), then continue at step 5.1.
- No: continue at step 5.1.
- Cannot tell: treat as Yes and note the reason in the run record.

Rules: give each decision an ID, state the default when the test cannot be run, and never let a branch end without a next step, an exit, or an escalation.

6. Set acceptance criteria and records

Acceptance criteria describe the finished output, not the effort. Write them so a person who did not do the work can check them in minutes:

• The output exists in the named place, in the named format.
• Named fields or values match their sources, within a stated tolerance.
• Approvals required by the SOP are present and dated.
• The run record is complete: performer, date, inputs used, decisions taken, deviations logged.

Pair every criterion with the record that proves it. If a step matters, it leaves evidence. If it leaves no evidence, say so on purpose in the records section rather than by accident.

7. Write the deviation path before you need it

Real runs fail in predictable places: a system is down, an input is missing, a value falls outside every branch. For each likely failure, state who can authorise a workaround, what workaround is allowed, what is never allowed, and how the deviation gets recorded and reviewed. A deviation that is recorded is data for the next revision. A deviation that is hidden becomes the unofficial process.

8. Test the draft with a cold walkthrough

Do not publish an untested SOP. Run both tests in references/review-checklists.md:

1. Desk walkthrough: a reviewer who did not write the draft follows it against three sample cases: one normal run, one run that hits a decision branch, and one run where a step fails. At each step they answer: do I know what to do, do I have what I need, and will I know it worked?
2. Live pilot: a real performer does the real task using only the document. The author watches, says nothing, and writes down every question, hesitation, and workaround. Each one is a defect in the document, not in the performer.

Fix the defects, then have the owner approve. Approval means the owner accepts the review date and the duty to keep the document true.

9. Publish as a controlled document

• Put the approved version in one canonical place and link to it from where the work starts. Copies saved elsewhere go stale.
• Mark superseded versions clearly and keep them readable for audit, out of the performer's path.
• Announce the change to every role named in the document, with a one line summary of what changed.
• Set the review date at publication. Base the interval on risk and rate of change: high risk or fast changing processes get six months, stable low risk processes get up to two years. A date picked with no reason is a date that gets ignored.

10. Maintain it

Review early when any trigger fires: the process changes, a tool or system changes, an incident traces back to the procedure, an audit raises a finding, the same deviation appears twice, or a performer reports a step that no longer matches reality. At review, the owner confirms the document still matches practice, folds recorded deviations into the text where they have become the real method, bumps the version, and logs the change in the revision history. Retire an SOP when the process ends, and say where its records live now.

For agent executed SOPs, add three fields to the run record: the agent or model identity, the inputs exactly as received, and any step where the agent stopped and asked a human. Agent runs drift in ways human runs do not, and the record is how you find out.

Output Contract

Deliver, in this order:

1. The completed SOP as a single document, filled from assets/sop-template.md, with no placeholder text left standing.
2. A decision table when the procedure has three or more decision points: decision ID, condition, test, branch outcomes.
3. The walkthrough results: cases run, defects found, and how each defect was fixed or accepted by the owner.
4. A maintenance line: owner, review date, and the triggers that force an early review.

A worked example ships in references/worked-example.md (refunding a duplicate charge). Match its level of detail: every step checkable, every branch closed, every run leaving a record.

Operating Rules

1. Never invent values. Thresholds, deadlines, system names, and approval limits come from the process owner or a source document. Mark a value as [OWNER TO CONFIRM: ...] rather than guessing, and list every such marker in your delivery note.
2. One process per document. Split at process boundaries, link across with document IDs.
3. Write for the least experienced qualified performer, not for the expert who taught you the process. Experts skip steps in interviews because the steps feel obvious.
4. The document loses every argument with reality. If performers do the work a different way and their way works, the SOP is wrong until proven otherwise: investigate, then update the document or retrain the performers, and record which.
5. Keep the SOP and the training material separate. The SOP is the reference at the point of work. Background and theory belong in a guide that the SOP links to.
6. Run bin/check_sop.py <draft.md> before review. It flags missing sections, banned vague words, steps with no verb, and decision points with no default. Treat its output as a defect list, fix what it finds, and note any flag you accept on purpose.
7. No em dashes in delivered text. Use commas, periods, or colons.