SOP Builder

Problem

Teams often keep processes in meetings, chat history, or one owner’s habit, so execution drifts over time. Rules captured during retrospectives may never become documentation, and the next run still depends on memory. SOP Builder is not about “writing an SOP”; it is about turning already-understood work requirements into a structured, executable, iterative, and pre-execution-checkable process document.

How It Works

The skill runs a multi-turn conversation: it first restates the request and confirms goals, triggers, roles, key outputs, and boundaries; then it splits the workflow into 3–7 phases, each with a goal, steps, output, and exit condition; finally it produces a Markdown SOP with a version-change log. Its constraints include not making workflow decisions for the user, keeping steps concrete, avoiding SOP-ization of trivial tasks, and converting emotional complaints into boundary conditions or pitfall notes. Before executing similar work, it also checks applicability, phase coverage, expected outputs, and uncovered differences.

Boundaries

It is suitable for documenting a process that has already been thought through, not for designing complex organizational workflows from scratch, and it does not replace PMP, ISO, legal, security, or compliance judgment. If the process changes frequently or roles shift often, a lightweight rules list or decision tree may be better than a full SOP.