SOP Writer . Agency OS

What it does

Takes a process that currently exists only in your head, in scattered notes or in a rambling voice note, and turns it into a complete standard operating procedure: why the process exists, what is in and out of scope, a RACI view of who does, owns, is consulted and informed at each step, the steps themselves with a trigger and an output for each, an exceptions table for the moments it goes wrong, and the metrics that tell you the process is actually working. If a document already exists it formalises what you have; if nothing exists it interviews you, mirroring your own words back rather than imposing jargon. Every SOP lands as its own file under your workspace, and existing SOPs get updated in place rather than silently overwritten.

Say this to start

This skill has no button. You start it by saying what you want. The fastest route is to voice-note yourself explaining the process as if to a new hire, paste the transcript, and ask for the conversion. Any of these will do it:

> turn this into an SOP

> write an SOP for how we onboard new clients

> document this process

> who owns what in our invoicing process

> put a proper process in place for handling refunds

When to reach for it

a process only works when a specific person is in the room, usually you
you are about to hand a recurring task to a team member or a new hire
the same task gets done a different way every time it comes up
nobody can say who actually owns a step, so it keeps falling through
you have notes, a checklist or a voice-note transcript that needs to become a real document
you are preparing to automate a process and need the procedure written down first

When NOT to use it

If you actually want	Use this instead
a client-facing proposal or scope of work	`proposals`
a new hire's ramp plan for their opening months	`onboarding-plan`, which can link out to the SOPs this skill produces
company policy: rules of employment such as leave, conduct or remote work	an HR or legal adviser. Policy is an HR-legal document, not a process, and this skill will decline it.
an automation built inside a connected tool	write the SOP here first, then hand it to whatever builds the automation. This skill writes the procedure such a build would follow, it does not build it.

Before you start

What you need	Why
An active workspace selected	the SOP files save under the workspace's operations folder, so the skill needs to know whose business this is	Required
The process source: pasted notes, an existing document, a voice-note transcript, or you available to answer questions in chat	everything in the SOP comes from what you supply. With notes it reads first and only asks what the notes do not answer; with nothing it runs an interview	Required
The real names of who touches each step	the RACI uses actual people where known and falls back to roles otherwise. Named owners make the document executable on day one	Optional
The most common ways the process goes wrong	these become the exceptions table. If you cannot recall them now, the skill will ask, because an SOP with no exceptions section is a happy-path fantasy	Optional
A decision on review cadence	every SOP carries a review rhythm so it does not rot; quarterly is the default if you do not choose one	Optional

How it runs

CaptureReads whatever exists first: notes, a pasted doc, a transcript. Only asks what those do not answer. With nothing to read, it interviews you: what starts the process, what the steps are, who touches each one, where it usually goes wrong, and what done looks like. Questions come in sequence, not as a wall, and it mirrors your words rather than translating them into consultant-speak.
Draft the SOPWrites the document in a fixed structure: a header with owner, last-updated date and review cadence, then purpose, scope, RACI, steps, exceptions and metrics. Each step gets a who, a trigger, the how, and the output it produces. Real team names where known, roles otherwise.
Pressure-test the edge casesAsks for the most common exceptions, the "what happens when the customer cancels mid-way" moments, and records each scenario with what to do. Anything you are unsure about goes in as an open [CONFIRM] question rather than a made-up rule.
Agree the metrics and review cadenceSettles a small set of measures with a target and a way to measure each, plus when the SOP gets re-read, quarterly by default. A process document nobody re-reads drifts back into someone's head.
Save without clobberingEach process gets its own file under the workspace's operations/sops/ folder. An existing SOP is never overwritten: it is updated in place with a fresh last-updated line, or the skill asks first.

What you get

An SOP file per process at brand/[workspace]/operations/sops/[process-name].md
A header line naming the owner, the last-updated date and the review cadence
A purpose statement and an explicit scope: what is in, what is out
A RACI matrix showing responsible, accountable, consulted and informed against each step
Steps written as who, trigger, how and output, so a team member can execute without you
An exceptions table mapping each failure scenario to what to do about it
Metrics with a target and a measurement method for each
Findings surfaced, not buried: unowned steps flagged, uncertain policy marked [CONFIRM], unnamed third parties recorded as such

Honest limits

Read this before you rely on it

Gaps are flagged as [CONFIRM], never papered over. If a step has no owner, the SOP says so and the step stays unowned until you assign it; the skill will not quietly hand it to whoever was mentioned nearby. If you say "we keep the deposit, I think", that lands as a recorded question, not a stated rule.
It writes process docs, not HR policy docs. Leave, conduct, remote work and other rules of employment are HR-legal territory and the skill will point you elsewhere rather than draft them.
Nothing is invented. Every step, name and exception traces back to your words, your notes or your files, which means the SOP is only as complete as what you tell it. A vague walkthrough produces a document full of open questions, which is the correct outcome, not a bug.
It documents the process; it does not run it, enforce it or automate it. Getting the team to actually follow the SOP is management work the file cannot do for you.
A request to document everything becomes a prioritised list first, then each process in its own file. Expect a queue, not a single mega-document.

Where people go wrong

The mistake	Do this instead
Asking for every process in the business at once	Let the skill prioritise, then work through the queue. Each process gets its own file, which is what makes them findable and maintainable.
Expecting the skill to guess who owns the chasing, the checking, the follow-up	An unowned step is a finding, not a blank to fill. Assign the owner yourself, then have the SOP updated.
Shipping the SOP to the team with `[CONFIRM]` markers still in it	Resolve every open question first. A team executing against unconfirmed policy is worse than no SOP at all.
Describing only the happy path	Volunteer the failure modes: the cancellation, the late payment, the outsourced vendor who disappears. The exceptions table is where the SOP earns its keep.
Trying to get a leave or conduct policy out of it	That is an HR-legal document. This skill writes how work gets done, not the rules of employment.
Writing the SOP and never looking at it again	Keep the review cadence you agreed. A stale SOP quietly diverges from reality and the team learns to ignore it.

Worth knowing

The lowest-effort input is a voice note. Talk through the process the way you would explain it to a new hire on their first day, paste the transcript, and say "turn this into an SOP". The skill keeps your phrasing, pulls the structure out of the ramble, and marks everything you hedged on as a question to confirm rather than a fact.