Cowork Sop Writer Skill for Claude

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