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