/008-sop-writer

name: sop-writer
description: >
  Transforms any process description — however rough, incomplete, or disorganized — into
  a clear, delegatable Standard Operating Procedure (SOP). Use this skill every time the
  user wants to document a process, create a procedure for a team member or VA, build
  an operations manual, standardize a workflow, or says things like "write an SOP for this",
  "help me document this process", "I need to delegate this", "create a procedure for my VA",
  "turn this into a checklist someone else can follow", "document how I do X", or pastes
  any description of how they do something and wants it structured. Always trigger this
  skill when the goal is to make a process repeatable and delegatable — even if the user
  phrases it casually or informally.

SOP Writer

Turns any process description — bullet points, voice transcripts, half-explained workflows, or detailed outlines — into a structured, delegatable Standard Operating Procedure.

The output is always specific, tool-aware, edge-case-aware, and ends with a built-in delegability test. It works for solopreneurs, ops managers, and founders alike.

---

Before you start

Read the user's input carefully and classify it into one of these input types:

| Type | Signals | Action | |---|---|---| | **Verbal / stream of consciousness** | Informal, jumps around, missing sequence | Run full elicitation (3.2) | | **Disorganized bullets** | Has structure but missing tool/trigger/output details | Run partial elicitation (3.3) | | **Semi-structured description** | Steps in order, some tools mentioned | Fill gaps only, then produce | | **Loom transcript / audio dump** | Long, repetitive, with digressions | Extract, then confirm before producing |

If the input is too vague to even classify, ask one question only: *"Can you describe what happens from start to finish when you run this process — even roughly?"*

---

Step 1 — Identify the SOP type

Before eliciting or producing anything, classify the process into one of these types. The type determines the output format (see Section 4).

• **Type A — Delegation to VA/contractor**: process will be executed by someone external
• **Type B — Editorial / content process**: publishing, writing, content workflows
• **Type C — Onboarding**: new client, new hire, new tool rollout
• **Type D — Recurring operational**: daily/weekly/monthly repeating tasks
• **Type E — Crisis / exception handling**: non-standard situations, escalations

If unclear from input, infer from context. If still unclear, ask: *"Who will be running this process — you, or someone else?"* and *"Is this something that happens on a schedule, or when something specific occurs?"*

---

Step 2 — Elicitation logic

The 6 mandatory fields

Before writing the SOP, you need these. Extract them from input if present. If missing, ask for them using the decision logic below.

1. **Process name** — what is this SOP called? 2. **Executor** — who runs it? (role, not person name) 3. **Trigger** — what causes this process to start? 4. **Expected output** — what is objectively true when the process is done correctly? 5. **Tools involved** — which apps, platforms, or software are used? (include obvious ones like email, Google Drive) 6. **Frequency** — how often does this run?

Decision logic: when to ask vs. when to infer

Count missing mandatory fields:
 
3 or more missing → Ask in one block, max 3 questions at a time
1–2 missing       → Ask 1 question, then proceed
0 missing         → Produce the SOP directly

Never ask more than 3 questions per turn. Never run a questionnaire. Behave like an ops consultant extracting information in conversation, not a form.

Elicitation question bank (use as needed, never all at once)

**For trigger and output (highest priority):**

• "What kicks this process off — does something arrive, does a day of the week come, does someone ask you something?"
• "When this process is finished correctly, what's different in the world? What can you point to and say 'done'?"

**For tools and executor:**

• "Which tools or platforms get touched during this process? Even basic ones like email or Docs."
• "Who will actually run this — you, a VA, a team member?"

**For edge cases (this is the differentiator — always ask if not mentioned):**

• "Has this process ever gone wrong? What happened?"
• "Is there any step where the person running it has to make a judgment call or 'figure something out'?"

**For frequency and variants:**

• "How often does this run?"
• "Is there a 'normal' version and an 'urgent' or 'exception' version?"

Graceful degradation rule

If the user doesn't provide all fields, never invent steps or details.

• **Infer** what you can from context (e.g., "you mention Notion → tool is Notion")
• **Mark** unresolvable gaps with `[TO COMPLETE]`
• **Never fabricate** specific steps, tool names, or criteria not described by the user

---

Step 3 — Determine output format

Ask (or infer from context) where this SOP will live:

| Destination | Output format | |---|---| | Notion / Obsidian | Markdown with section emoji | | Google Docs / Word | Clean Markdown, no emoji | | ClickUp / Asana | Flat numbered steps, no nesting | | Email to VA | Flowing text, steps in bold | | Not specified | Default: Markdown with emoji |

Also determine **detail level** based on executor:

• **Executor = VA or external collaborator** → Expanded format (include where to click, what to type)
• **Executor = founder / user themselves** → Compact format (one line per step)

---

Step 4 — Write the SOP

Use the **Universal Base Structure** below, then apply the **Type Variant** on top.

Universal Base Structure

# [PROCESS NAME]
 
**Version:** 1.0 | **Created:** [date] | **Review by:** [date + 6 months]
 
---
 
## 📋 Process overview
- **Executed by:** [role]
- **Trigger:** [what starts this process]
- **Frequency:** [how often]
- **Estimated time:** [X minu