cowork-sop-writer

name	cowork-sop-writer
description	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.

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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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