process-documentation

name	process-documentation
description	Turn rough operational knowledge into a clear SOP, runbook, workflow guide, or process document with roles, triggers, steps, edge cases, escalation, and outputs. Use when the user asks to document a process, write a runbook, capture a workflow, create an SOP, map how something works, or make a repeatable procedure executable by others.

process-documentation

Turn rough process knowledge into executable documentation.

Goal

Produce a document that makes a repeatable workflow clear enough for another person or agent to follow without guessing.

Core principles

• Prefer clarity over elegance.
• Document triggers, not just steps.
• Distinguish normal flow from edge cases.
• Make escalation explicit.
• Capture outputs and proof of completion.

Choose the output type

SOP

Use for stable recurring procedures.

Runbook

Use for operational response, troubleshooting, or recovery flows.

Workflow guide

Use for bounded collaborative or administrative processes.

Standard workflow

1. Frame the process

Capture:

• process name
• purpose
• owner
• frequency or trigger
• tools involved
• prerequisites

2. Define scope

State explicitly:

• what is in scope
• what is out of scope
• where the process starts
• what counts as completion

3. Normalize the steps

For each step, capture:

• who
• when
• how
• output
• tool / system

4. Add non-happy-path handling

Document:

• edge cases
• common mistakes
• escalation path
• rollback or recovery if relevant

5. Finalize for execution

Ensure the document can be followed by someone new to the process.

Output contract

Minimum sections:

• Purpose
• Scope
• Prerequisites
• Roles and responsibilities
• Process steps
• Edge cases / exceptions
• Escalation path
• Review cadence or next review date

Prefer one of three concrete output types:

• SOP
• Runbook
• Workflow guide

Choose explicitly; do not leave the document as an ambiguous hybrid unless the user asked for that.

Quality gates

Before finalizing, verify:

• the trigger is explicit
• each step has an owner or role
• outputs are visible
• edge cases are not buried
• escalation is concrete
• the process can be executed without hidden context
• the chosen output type (SOP / Runbook / Workflow guide) is obvious from the document

Boundaries

Do not use this skill when the task is primarily:

• strategy or design choice → use design-architect
• post-incident analysis → use incident-postmortem
• executive compression of an existing document → use executive-summary

Read references as needed

• references/sop-template.md — recurring stable process format
• references/runbook-template.md — operational and incident-oriented process format
• references/escalation-patterns.md — escalation structures and guidance