Turn a process walkthrough -- meeting transcript, screen-recording transcript, rough notes, or a folder of scattered how-to docs -- into a clean standard operating procedure: numbered steps, roles, decision points, exceptions, and a consistent template across your whole SOP library.
SkillScore83Maintained
Automatic
◆Doc Ops pack
Last verified 8/24/2026
What it changes
Passed 19 of 23 test cases with the skill, and 15 of 23 without it.
Without skill65%
With skill83%
Checks it passed that the model alone missed
The purpose section consists of a single sentence.
The SOP header includes a last verified date entry.
The decision branch specifies routing to VP approval once the threshold is met.
and 5 more in the full report
5 fixed14 passed either way3 still failing1 broke
Pass-rate lift
+17 pp
Tokens
+45%
Agent turns
0%
Response time
+9%
Model gemini-3.6-flashMeasured 8/24/2026v119 of 23 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 5
Prompt
Write the purpose section for an SOP on quarterly server log archival. Make sure it succinctly defines why this document exists.
What was checked, without and with the skill
Checked
Without skill
With skill
The purpose section consists of a single sentence.
Missed
Passed
The purpose sentence states the objective of quarterly server log archival.
Passed
Passed
case-14 · gemini-3.6-flash · 8/24/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md27 linessingle file
Cowork SOP Writer
Write procedures the way a good operations manager does: capture how the work is actually done, make the implicit explicit, and write for the new hire on their worst day -- not for the expert who already knows. Input: any record of the process (transcript of someone walking through it, Loom/recording transcript, chat thread, rough notes, or existing scattered docs) and, optionally, an existing SOP folder to match style.
Workflow
Extract the process. From the source material, pull the sequence of actions, the tools/systems touched, the inputs required to start, the outputs that define done, and who does what. Note every place the narrator said "usually", "unless", "it depends", or "just ask [person]" -- those are the decision points and tribal knowledge the SOP exists to capture.
Interview the gaps. List what the source did not cover: unnamed systems, missing credentials/access requirements, undefined edge cases, steps that assume knowledge. Ask the user to fill the critical ones; mark the rest [TO CONFIRM] inline rather than guessing.
Draft. Write the SOP: purpose (one sentence), owner and roles, prerequisites, numbered steps (one action per step, the verb first, the system named, the expected result stated), decision points as explicit if/then branches, exceptions and how to handle them, escalation path, and definition of done. Insert [SCREENSHOT: what it should show] placeholders where a visual would prevent an error.
Pressure-test. Re-read as the new hire: can every step be executed without asking anyone anything? Any step that requires judgment gets either the judgment criteria written down or an explicit "ask [role]" instruction. Flag steps where the process itself looks fragile (single person dependency, manual copy-paste between systems) in a separate "process risks" note to the owner -- not in the SOP body.
Library consistency. If an SOP folder was provided, match its template, heading structure, and naming convention. If none exists, propose one (sop-[team]-[process-name].md with a standard header block: owner, last verified date, systems touched) and offer to retrofit existing docs.
Rules
Document the process as performed, then flag improvements separately. An SOP that silently "fixes" the process documents fiction.
One action per step. "Log in and pull the report and email it" is three steps.
Name real systems and real roles, never "the tool" or "someone from finance."
Tribal knowledge is the payload: every "it depends" from the source must end up as either written criteria or a named escalation.
Never fabricate steps to fill a gap -- [TO CONFIRM] beats plausible fiction that a new hire will execute literally.
Every SOP carries a "last verified" date and an owner. An unowned SOP is already stale.
Quick Commands
"SOP from [transcript/file]" -- full workflow
"What's missing?" -- step 2, the gap interview only
"Match my library at [folder]" -- restyle a draft to the existing template
"Audit my SOP folder" -- staleness and consistency report across an existing library