Build a standard operating procedure end to end: capture the process brief, infer its shape, draft the SOP, derive a run checklist, and define the metrics that prove it is working. Use when the user wants to turn a fuzzy, in-someone's-head process into a documented, repeatable SOP with a checklist and success metrics. Do NOT use for a single quick edit to an existing SOP, or when the user only needs a one-line answer rather than a structured multi-step build.
Scanned 9/2/2026
Install to Claude Code
npx -y skills add FerroxLabs/wayland --skill business-ops-sop-generator --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Business Ops Sop Generator?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/ferroxlabs-business-ops-sop-generator)More formats (shields.io, HTML) on the badges page.
---
name: business-ops-sop-generator
description: >-
Build a standard operating procedure end to end: capture the process brief,
infer its shape, draft the SOP, derive a run checklist, and define the metrics
that prove it is working.
Use when the user wants to turn a fuzzy, in-someone's-head process into a
documented, repeatable SOP with a checklist and success metrics.
Do NOT use for a single quick edit to an existing SOP, or when the user only
needs a one-line answer rather than a structured multi-step build.
license: Apache-2.0
type: workflow
skills: "ops-process-doc ops-sop ops-checklist"
metadata:
author: wayland
version: 1.0.0
tags: business-ops sop process documentation step-by-step
category: Business Operations
depends: "ops-process-doc ops-sop ops-checklist"
---
# Build an SOP
**Estimated time:** 20-30 minutes
This workflow turns an undocumented or tribal-knowledge process into a clean,
repeatable Standard Operating Procedure. It captures the process, infers its
structure, drafts the procedure, derives a run checklist, and defines the
metrics that tell you the SOP is actually working. Treat each step's output as
the input to the next; review and refine a step before advancing.
## Steps
**Step 1: Capture the Process Brief**
Open by telling the user you will build an SOP for this process, then ask them
for: what process this covers, how frequently it runs, who runs it today, and
where the pain is. Ask these as a single grouped question and wait for the
answer. Record the response verbatim as the brief; it is the source material
for every later step.
- Input: user description of the process, frequency, current owner, pain points
- Output: a captured process brief
- Key focus: get a concrete, specific process scope before generating anything
**Step 2: Infer the Process Shape** (uses: ops-process-doc)
From the brief, infer whether the process is linear, branching, or cyclical.
State the inferred shape clearly and give a one-paragraph reasoning for why the
process fits that shape. Surface the inference to the user as a justification so
they can correct it if wrong before you draft the SOP.
- Input: process brief from Step 1
- Output: inferred process shape (linear / branching / cyclical) with reasoning
- Key focus: pick the structural backbone the SOP steps will hang on
**Step 3: Draft the SOP** (uses: ops-sop)
Draft the full SOP from the brief and the inferred shape: a clear process
description followed by an ordered, numbered step sequence with the owner and
trigger for each step. Show the draft to the user and ask whether to refine it
or proceed to the checklist. If they ask for changes, revise the SOP against
their feedback and show it again. Allow up to three refinement passes before
moving on.
- Input: process brief from Step 1, process shape from Step 2, user refinement feedback
- Output: a reviewed SOP draft (process description plus ordered step sequence)
- Key focus: each step has a clear action, owner, and trigger
**Step 4: Derive the Run Checklist** (uses: ops-checklist)
Convert the approved SOP into a tick-box run checklist a single operator can
follow live. Each SOP step becomes one or more concrete checklist items phrased
as verifiable actions. Show the checklist to the user.
- Input: approved SOP from Step 3
- Output: a per-run execution checklist mapped to the SOP steps
- Key focus: every checklist item is a single, verifiable action
**Step 5: Define Process Metrics** (uses: ops-process-doc)
Define the metrics that show the SOP is working: cycle time, error or rework
rate, throughput, and any quality gates relevant to this process. Show the
metrics to the user and ask whether to refine them or ship the SOP package. If
they ask for changes, revise the metrics against their feedback and show them
again. Allow up to two refinement passes.
- Input: approved SOP from Step 3, user refinement feedback
- Output: a reviewed set of process metrics with target values where known
- Key focus: choose metrics the team can actually observe and act on
**Step 6: Assemble and Ship the SOP Package**
Assemble the final deliverable as a single document containing: the process
shape, the SOP, the checklist, and the metrics, titled with the process name
from the brief. Confirm the package is complete and hand it to the user.
- Input: brief, process shape, SOP, checklist, metrics from prior steps
- Output: the assembled SOP package document
- Key focus: one coherent artifact the team can adopt immediately
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!