/process-doc

> If you see unfamiliar placeholders or need to check which tools are connected, see CONNECTORS.md.

Document a business process as a complete standard operating procedure (SOP).

Usage

/process-doc $ARGUMENTS

How It Works

Walk me through the process — describe it, paste existing docs, or just tell me the name and I'll ask the right questions. I'll produce a complete SOP.

Output

## Process Document: [Process Name]
Owner: [Person/Team] | Last Updated: [Date] | Review Cadence: [Quarterly/Annually]

Purpose
[Why this process exists and what it accomplishes]

Scope
[What's included and excluded]

RACI Matrix
| Step | Responsible | Accountable | Consulted | Informed |
|------|------------|-------------|-----------|----------|
| [Step] | [Who does it] | [Who owns it] | [Who to ask] | [Who to tell] |

Process Flow
[ASCII flowchart or step-by-step description]

Detailed Steps

#### Step 1: [Name]
Who: [Role]
When: [Trigger or timing]
How: [Detailed instructions]
Output: [What this step produces]

#### Step 2: [Name]
[Same format]

Exceptions and Edge Cases
| Scenario | What to Do |
|----------|-----------|
| [Exception] | [How to handle it] |

Metrics
| Metric | Target | How to Measure |
|--------|--------|----------------|
| [Metric] | [Target] | [Method] |

Related Documents
[Link to related process or policy]

If Connectors Available

If ~~knowledge base is connected:

• Search for existing process documentation to update rather than duplicate
• Publish the completed SOP to your wiki

If ~~project tracker is connected:

• Link the process to related projects and workflows
• Create tasks for process improvement action items

Tips

• Start messy — You don't need a perfect description. Tell me how it works today and I'll structure it.
• Include the exceptions — "Usually we do X, but sometimes Y" is the most valuable part to document.
• Name the people — Even if roles change, knowing who does what today helps get the process right.