Menu

Individual skill

cowork-sop-writer

0upvotes

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/SKILL.md

Read pinned source

Source commit b2267d9171af4f56848d82992381b20b89b44056

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
Yes
Repository scan complete
No
Skill scan complete
No
Observed behavior
Instructions only
Last checked
Nov 10, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
425
Repository last updated
Oct 20, 2026
License
MIT

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt

# 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
Back to top