# Process Doc

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

- Skill: `rongxinzy/process-doc` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add rongxinzy/process-doc`
- Raw SKILL.md: https://api.skillmd.com/api/skills/rongxinzy/process-doc/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- License: Apache-2.0
- Author: rongxinzy (https://skillmd.com/u/rongxinzy)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/rongxinzy/process-doc

---


<!-- Changes: added license field to frontmatter and removed obsolete placeholders and a broken ../../CONNECTORS.md reference. Original source: https://github.com/anthropics/knowledge-work-plugins/tree/main/operations/skills/process-doc (Apache-2.0) -->

# /process-doc

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

```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]
```

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