---
name: sop-writer
description: Write a clear standard operating procedure that anyone can follow to do a task the same way every time. Use this skill whenever a user needs an SOP, a standard operating procedure, a documented process, a how-to for their team, or says 'document this process', 'write an SOP for', or 'we need this written down so anyone can do it'. Trigger whenever tribal knowledge needs to become a repeatable, followable procedure.
---

# SOP Writer

## What this does and why it matters
A business that depends on people remembering how to do things does not scale and breaks when someone leaves. This skill turns a described task into a clear standard operating procedure that a new person can follow to the same result, without the original expert in the room. Documented process is what makes a business delegable and sellable.

## Inputs to gather
1. The task or process to document and its purpose.
2. Who performs it and what triggers it.
3. The steps, as the expert does them (walk through it if needed).
4. The tools, access, and inputs required.
5. What a correct outcome looks like and common mistakes.

## Method

### 1. State purpose, scope, and trigger up front
Why the SOP exists, when it applies, and what kicks it off, so the reader knows if they are in the right place.

### 2. List prerequisites
Access, tools, inputs, and permissions needed before starting. A step-blocking prerequisite discovered mid-task wastes everyone's time.

### 3. Write steps as unambiguous actions
Numbered, imperative, one action each, specific enough that a capable newcomer succeeds without guessing. "Open the CRM" is weaker than "In HubSpot, open the deal record and set Stage to Proposal Sent". Note where a decision changes the path.

### 4. Show what right looks like
Include the expected result and, where useful, an example, so the performer can self-check.

### 5. Capture pitfalls and edge cases
The common mistakes and how to avoid them, plus what to do when the unusual case appears or who to escalate to.

### 6. Assign ownership and review
Who owns the SOP and when it should be reviewed, so it does not rot.

## Output format
ALWAYS use:

# SOP: [Process Name]
## Purpose and scope
## Trigger (when to run this)
## Prerequisites (access / tools / inputs)
## Steps (numbered, imperative, with decision branches)
## What a correct result looks like
## Common mistakes and edge cases
## Escalation
## Owner and review date

## Anti-patterns to avoid
- Vague steps that assume the reader already knows how.
- Missing prerequisites discovered mid-process.
- No definition of a correct outcome, so quality varies.
- No owner, so the SOP goes stale.

## Example
An SOP for onboarding a new client states the trigger (signed SOW), lists the tools and access needed, walks eight numbered steps with a branch for retainer vs project clients, shows the completed setup, and names the ops lead as owner.