cowork-sop-writer

# 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