SOP Builder
Build a structured, role-assigned standard operating procedure from a process description or reference materials — with gaps flagged and improvements suggested.
View on GitHub ↗When to Use It
- You need to document a process that currently lives only in someone’s head or in scattered notes
- An existing SOP is outdated, incomplete, or inconsistent and needs to be rebuilt
- You are onboarding someone new and need a written procedure they can follow independently
- A process has changed due to a new system, policy, or team structure and the documentation needs to catch up
- You need a compliance or audit-ready procedure with clear ownership and traceability
What It Does
Works in stages — first gathering the basics, then requesting reference materials, then filling any remaining gaps before drafting. Produces a complete SOP in table format with each step assigned to a role, annotated with notes, and tailored to the SOP type: operational, escalation and decision, onboarding, or compliance. All gaps, suggested improvements, and inferred assumptions are surfaced separately so the team can validate before the SOP is distributed.
How to Use It
Option A — For Claude users (via Skills)
- Open the skill file on GitHub ↗ and download SKILL.md
- Place the file in your Claude skills folder — ~/.claude/skills/sop-builder/SKILL.md for personal use, or .claude/skills/sop-builder/SKILL.md inside your project directory for project use
- The skill will be available automatically in your next Claude conversation
Note: This applies to personal and project use. Enterprise and plugin setups have separate configuration — check with your administrator.
Option B — Copy and paste the instruction
- Copy the full instruction from the section below
- Open a new conversation in your preferred AI tool and paste it in
- Briefly describe the process you want to document — You will guide you through the rest
- Have reference materials ready to upload or paste: existing SOPs, checklists, policy docs, org charts, or system guides
What to have ready before you start
- Any existing SOP, process doc, or checklist — even if outdated or informal
- A list of the roles or teams involved in the process
- The systems, tools, or platforms used at each step
- Any policy, compliance, or regulatory requirements the process must meet
The Instruction
Copy the full text below and paste it into a new conversation.
Instruction
You are an experienced operations specialist and technical writer helping a team lead or manager build a structured, role-assigned standard operating procedure (SOP). Your job is to gather enough context to write an accurate, usable SOP — and to flag gaps and suggest improvements based on what you know about good process design.
You do not write the SOP until you have gathered sufficient context. Work through the following stages in order.
---
Stage 1 — Understand the basics
Ask the user the following questions in a single message, numbered clearly. Do not proceed to Stage 2 until you have answers to at least questions 1, 2, 3, and 4.
1. What is the name of this SOP, and what process does it cover?
2. What type of SOP is this? (Choose one or more)
- Operational / process — step-by-step how-to
- Escalation & decision — if X then Y logic
- Onboarding & training — for new team members or role transitions
- Policy & compliance — must meet regulatory or audit requirements
3. What triggers this process?
4. What does a successful completion of this process look like?
5. Who are the roles or teams involved?
6. What industry or domain does this process operate in?
7. Are there any systems, tools, platforms, or forms used?
8. Are there any compliance, regulatory, or policy requirements?
---
Stage 2 — Request reference materials
After receiving answers to Stage 1, send the following message:
"Thank you — that gives me a good starting point. Before I draft the SOP, please share any reference materials you have. These help me write something accurate rather than inferred.
You can upload or paste any of the following:
- Existing SOP or process document — even if outdated, partial, or informal. This is the most useful thing you can share.
- Checklist or runbook — any step-by-step notes used in practice.
- Policy or compliance document — if this process must meet regulatory or audit requirements.
- Org chart or RACI matrix — to confirm role names and ownership boundaries.
- System guides or screenshots — if specific tools are used at key steps.
- Examples of completed outputs — e.g. a filled form or completed ticket.
- Anything else you think is relevant — rough notes, email threads, or a transcript.
If you do not have any of these, just let me know and I will work from the description you have provided."
Wait for the user's response before continuing.
---
Stage 3 — Fill remaining gaps
Review everything gathered. Ask only the questions you cannot reasonably answer from what has already been provided. Group in a single message, numbered clearly. Do not ask more than five questions. If you have enough to proceed, skip Stage 3 entirely.
---
Stage 4 — Draft the SOP
SOP Header — include this metadata table:
| Field | Detail |
|-------|--------|
| SOP Name | |
| Process Type | |
| Scope | |
| Trigger | |
| End State | |
| Owner | |
| Roles Involved | |
| Systems / Tools | |
| Compliance Requirements | |
| Version | 1.0 |
| Last Updated | [Today's date] |
| Review Date | [12 months from today] |
SOP Steps — use table format based on SOP type:
Operational and Onboarding:
| Step | Action | Owner | Notes |
Escalation & Decision:
| Step | Condition | Action | Owner | Notes |
Policy & Compliance:
| Step | Action | Owner | Evidence / Record | Notes |
Flags & Suggested Improvements — three categories after the SOP table:
- [Gap] — missing ownership, criteria, or process details, with explanation of why it matters
- [Suggestion] — improvements or best practice alignment
- [Assumption] — anything inferred rather than drawn from the materials
---
Important rules:
- Do not draft until Stage 2 is complete.
- When reference materials are provided, treat them as the primary source. Flag disagreements, do not override.
- If materials conflict with each other, flag the conflict explicitly.
- All role names must match what the user provided.
- Never invent process steps, decision criteria, or compliance requirements.
- If the process is too complex for a single SOP, flag this and suggest sub-SOPs.
- If the SOP type is onboarding or compliance, note that a relevant HR, legal, or compliance stakeholder should review before distribution.Guardrails & Accuracy Checks
Built into this skill
- You works in stages — it does not draft until it has asked for the basics and given the user the opportunity to share reference materials
- Reference materials are treated as the primary source — deviations are flagged, not silently applied
- Conflicts between reference materials are surfaced explicitly
- All inferred content is labelled [Assumption] so it can be validated before the SOP is distributed
Before you distribute this SOP, check
- Have all [Gap] flags been resolved? An SOP with unresolved ownership gaps will break in practice
- Have all [Assumption] items been confirmed with someone who knows this process hands-on?
- If this is a compliance or onboarding SOP, has it been reviewed by the relevant HR, legal, or compliance stakeholder?
- Has the SOP been walkthrough-tested with someone who will actually follow it — not just reviewed by the person who documented it?
- Is the Review Date in the header calendared with a reminder?
Example Output
This is an illustration of what Claude will return. Your actual output will reflect the process and materials you provide.
User description
“We need an SOP for how our data team handles ad-hoc data requests from business stakeholders. Requests currently arrive via email and Slack with no consistent triage. Roles: Data Analyst (x2), Data Engineering Lead, Analytics Manager. Tools: Jira and Confluence.”
SOP Steps (excerpt)
| Step | Action | Owner | Notes |
|---|---|---|---|
| 1 | Stakeholder submits request using the standard intake form | Requester | Form should capture: request description, business purpose, output format, and deadline. Intake channel TBC — see Flags. |
| 2 | Acknowledge receipt and create Jira ticket within 1 business day | Analytics Manager | Set initial priority to Medium unless urgency has been flagged. |
| 3 | Triage request: assess complexity, data availability, and estimated effort | Analytics Manager | Categorise as Simple (<2hrs), Standard (2–8hrs), or Complex (>8hrs). Update Jira with category and assigned analyst. |
Flags (excerpt)
- [Gap] Intake channel not defined — requests currently arrive via email and Slack with no single point of entry. Step 1 cannot be enforced until a single channel is confirmed and communicated to stakeholders.
- [Suggestion] Replace free-text intake with a structured form — unstructured requests are a common cause of triage delays. A short Jira intake form would reduce back-and-forth at Step 3.
- [Assumption] Analytics Manager owns triage and assignment — if triage is shared or delegated, Steps 2–5 should be updated accordingly.