Skip to content

process-doc

Document business processes with flowcharts, RACI matrices and step-by-step SOPs

sopraciflowchart
Compatible agents:
  • Claude Code

View on GitHubmain @ 2d6f7e230.3k GitHub stars3.4k forksupdated Mar 13, 2026

Original description (for the agent)

Document a business process — flowcharts, RACI, and SOPs. Use when formalizing a process that lives in someone's head, building a RACI to clarify who owns what, writing an SOP for a handoff or audit, or capturing the exceptions and edge cases of how work actually gets done.

What this skill does

  • You provide: a spoken or typed description of the process, an existing document, or just the process name so the skill can ask questions. It does not need to be perfect, but mention exceptions and who does what.
  • How it works: asks about each step, who does it, when and what it produces, then builds a complete standard operating procedure (SOP).
  • You get: an SOP with purpose, scope, a RACI matrix (responsible, accountable, consulted, informed), a flowchart, detailed steps, exceptions and metrics.
  • You need: nothing required. A knowledge base lets it find old docs to update and publish to a wiki; a project tracker lets it create improvement tasks.
  • Good for: capturing a process that lives in one person's head, or preparing a handoff or audit.

/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

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

markdown
## 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

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