sop-writer

---
name: sop-writer
description: Writes a process up as a numbered, owned SOP somebody else can run. Use for documenting a process, a handover, or a standard operating procedure.
---

# The process written down once, so somebody else can do it

An SOP a stranger to the job can follow and still get it right.

## Claude does

1. Ask for four inputs, guess none: {PROCESS_NAME}; how the job is done today ({WALKTHROUGH}); the owner and every role ({OWNER_AND_ROLES}); the real approval limits, SLAs and targets.
2. Apply the three-sentence scope test: purpose in one or two sentences, scope in three. If it does not fit, split into two SOPs.
3. Pick one of four formats and say why: simple checklist, complex linear checklist, watertight process (regulated or money-touching), or flow diagram.
4. Write the governance header: version, last-updated date, review schedule (monthly compliance, quarterly stakeholder, annual audit), named owner or DRI.
5. Number the steps. One action each, opening with an imperative verb in the present tense. A step joining two actions with "and" gets split.
6. Name each decision point as a question with branches, and each exception with what to do and who to tell.
7. Write `sop-spec.md`: header, purpose, scope, roles, ordered steps with owners, decision points, approval levels with SLAs and thresholds, exceptions, metrics.

## Then Codex does

Claude decides the shape and wording; Codex builds the document: the template, the ASCII map, a RACI grid of every step against every role, the approval and exception tables, a one-page checklist, and a lint of every step. Bulk work.

```
codex exec --sandbox danger-full-access --skip-git-repo-check -C "<working folder>" - < CODEX.md
```

Fill in first: {PROCESS_NAME}, {SPEC_FILE} (path to `sop-spec.md`), {OWNER_AND_ROLES}, {FORMAT}.

## Claude checks

1. Document step count equals the spec.
2. Every step opens with an imperative verb and joins no two actions with "and". Most SOPs fail here, so one breach rejects the file.
3. Purpose two sentences or fewer, scope three, header carrying version, date, review schedule and named owner.
4. Every RACI row has exactly one Accountable, and every owner is a named role, never "the team".
5. No SLA, threshold or target that was not supplied. An invented number is a rejection.
6. Fresh-eyes test: any step needing knowledge not on the page is rewritten.
7. Reject and rerun: fix `sop-spec.md` and rerun, never hand-patch Codex's output.

## Rules

- Fails the three-sentence test, split the SOP.
- One action per step. "And" means two steps.
- Never ship an SOP nobody has piloted: one non-owner runs it, then a superior reads it fresh.
- Never invent an SLA, approval limit, tolerance or target. Ask, or mark it missing.
- Public information only.
- Never invent a fact, a number or a quote.
- Anything sent in someone's name says whose name it is.

## If Codex is not installed

Claude builds the document, tables and map itself and says so.

## Built from

- w95/awesome-claude-corporate-skills, https://github.com/w95/awesome-claude-corporate-skills - 189 stars (api.github.com, 5 Sep 2026); the six components, RACI, SLA approval chains.
- Process Street, https://www.process.st/writing-standard-operating-procedures/ - four formats, verb-first rule, pilot and fresh-eyes gates.
- Anthropic Agent Skills best practices, https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices - authoring standard.
- obra/superpowers, https://github.com/obra/superpowers - 281,934 stars (api.github.com, 5 Sep 2026); verification before completion.

# The process written down once, so somebody else can do it - Codex task

## You are given

- {PROCESS_NAME} - the process being documented.
- {SPEC_FILE} - path to `sop-spec.md`. Holds header fields, purpose, scope, roles, ordered steps with owners, decision points, approval levels with SLAs and escalation thresholds, exceptions, and metric targets. It is the only source of truth.
- {OWNER_AND_ROLES} - the named owner or DRI, plus every role in the process.
- {FORMAT} - one of `simple-checklist`, `complex-linear-checklist`, `watertight-process`, `flow-diagram`.

## Produce

In the working folder:

1. `SOP-<process-name>.md` - the full document in this order: governance header (version, last-updated date, review schedule, named owner), purpose, scope, roles, numbered steps, decision points, approval chain, exceptions, metrics. Lay the steps out in the style {FORMAT} calls for.
2. `raci.md` - a grid of every step (rows) against every role in {OWNER_AND_ROLES} (columns), each cell R, A, C, I or blank. Exactly one A per row.
3. `process-map.txt` - an ASCII map: every numbered step a box, every decision point a branch with named outcomes, every exception an exit.
4. `approval-chain.md` - a table of level, approver role, triggering threshold, SLA, escalation path if the SLA is missed. Values copied from {SPEC_FILE} only.
5. `checklist.md` - the one-page version, one tick box per step, no prose.
6. `lint.md` - one row per step: number, first word, whether that first word is an imperative verb, whether the step contains " and " joining two actions, PASS or FAIL.

## Rules

- Copy every step, owner, threshold, SLA and metric verbatim from {SPEC_FILE}. Never add a step, merge two, reorder them or improve the wording.
- Never invent a number. A missing threshold, SLA or target becomes `[MISSING: what is needed]`, recorded in `lint.md`.
- Do not rewrite or split a failing step. Flag it FAIL in `lint.md` and leave it exactly as written.
- Every owner is a named role from {OWNER_AND_ROLES}. Never "the team", "someone" or "TBC".
- Do not edit {SPEC_FILE}.
- Deterministic: the same inputs produce identical output.

## Return

Print, in this order:

1. Step count in {SPEC_FILE} and in `SOP-<process-name>.md`. State plainly whether they match.
2. Sentence count of purpose and of scope.
3. Steps failing the verb-first check, with their numbers.
4. Steps containing " and " joining two actions, with their numbers.
5. Number of RACI rows, and any row without exactly one A.
6. Every `[MISSING: ...]` marker and the file it sits in.
7. Approval levels written, and any lacking a threshold or an SLA.
8. The first ten lines of `SOP-<process-name>.md`.