| name | sop-writer |
| description | Write a delegation-ready SOP. Trigger on "write an SOP", "document this process", "create a procedure", "process documentation", "how-to guide", "write up the steps for", "create a runbook", or any request to turn a process into a reusable document. Also fires when the user describes how something works and wants it captured for someone else to follow.
|
| why | Documents a process so it can run without the founder in the room - the goal is a document a smart person who has never done this task can follow to completion. |
| enhance | Fill stack.json with your actual tools before running so TOOLS NEEDED names your real CRM, automation platform, and email client rather than generic labels the delegate cannot look up. |
| allowed-tools | ["Read"] |
| mcp_requirements | [] |
SOP Writer
Runs on: reasoning - reads your files and reasons; any capable agent can run this.
The goal: someone who has never done this task before should be able to complete it by following this document. No phone calls to the founder.
Before You Write
Read three files first so the SOP is specific to the user's stack and voice, not generic.
stack.json at the Founder OS root. Maps the user's placeholder tools to actual products (e.g. knowledge_base: notion, email_platform: outlook, automation_platform: n8n). When you populate the TOOLS NEEDED section, name the user's actual tool. Do not write "your CRM" if stack.json says crm: hubspot. If a relevant field is null, use the generic label and append [VERIFY].core/identity.md for the founder's name and primary business. Use these for the Owner field. Do not invent.core/voice-profile.yml via the your-voice skill. Apply voice.rhythm and voice.reading_level to the prose inside steps. SOPs that read at level 12 for an ops-focused founder who speaks at level 8 do not get followed.
Before drafting, read brain/.snapshot.md and check its date: line. If it is missing or more than 3 days old, do NOT treat it as current: read brain/flags.md and cadence/weekly-commitments.md directly for live state, and tell the user the snapshot is stale so they can ask for a refresh (any skill with shell access, or the next session close, rebuilds it). This skill's tool grant deliberately has no shell access, so it reports staleness rather than fixing it - a stale snapshot read as current presents last week's state as today's. Use the open-flags block to avoid topics that contradict current operator stance. Use the must-do block to lean the draft toward what the operator is actively working on. Use the voice and brand blocks (if present) to set tone. The freshness check above is not optional: skipping the regeneration and reading a week-old snapshot is the one way this block makes output worse.
SOP Structure
SOP: [Process Name]
Owner: [Who is responsible]
Last updated: [Date]
---
PURPOSE
[One sentence. Why does this process exist?]
WHEN TO USE
[What triggers this process?]
TOOLS NEEDED
[Software, access, templates required]
---
STEPS
1. [Action verb] [what to do]
- [Detail if needed]
Expected result: [What should happen]
2. [Action verb] [what to do]
Expected result: [What should happen]
---
IF SOMETHING GOES WRONG
-> [Problem]: [Fix]
-> [Problem]: [Fix]
-> [Problem]: Escalate to [Person/Role]
---
QUALITY CHECK
-> [How you know it was done correctly]
-> [Checkpoint]
Writing Rules
- Start every step with a verb. "Open the CRM" not "The CRM should be opened."
- One action per step. If it has "and", split it.
- Include expected results after each step.
- Write for a smart person who has never done this.
- Handle exceptions. The "if something goes wrong" section is what makes an SOP useful.
- Simple hyphens (-) not em or en dashes
- Numbered steps, arrows (->) for sub-items
What to Ask
- Walk me through it step by step
- What tools or systems do you use? (cross-check with
stack.json; only ask if missing or ambiguous)
- What goes wrong most often?
- Who does this currently? Who should be able to do it?
- How do you know it's done correctly?
