Process Documentation

Process Documentation Skill

by mohitagw15856 · MIT license · ★ 1,395 on GitHub · updated Sep 23

Document any business process in a clear, structured format. Use when asked to document a process, write a process guide, create a workflow document, or map out how something works.

---
name: process-documentation
description: "Document any business process in a clear, structured format. Use when asked to document a process, write a process guide, create a workflow document, or map out how something works. Produces a complete process document with steps, roles, inputs, outputs, and edge cases."
---

# Process Documentation Skill

Produces clear, structured process documentation that someone new to a role can follow without needing to ask questions.

## Required Inputs
- **Process name**
- **Process description** (rough notes are fine)
- **Who does this process** (roles involved)
- **How often it runs** (daily / weekly / monthly / event-triggered)
- **Tools involved**
- **Known edge cases**

## Output Structure

Overview

Produces clear, structured process documentation that someone new to a role can follow without needing to ask questions.

Manual install (npx, ZIP)

Claude Codenpx skills add mohitagw15856/pm-claude-skills --skill process-documentation -g -a claude-code

Claude Code (manual)

mkdir -p ~/.claude/skills && curl -sL https://codeload.github.com/mohitagw15856/pm-claude-skills/tar.gz/f6ca79348c55 \
  | tar -xz -C ~/.claude/skills --strip-components=2 pm-claude-skills-f6ca79348c55/skills/process-documentation

Windows (PowerShell)

New-Item -ItemType Directory -Force "$HOME\.claude\skills" | Out-Null; Invoke-WebRequest "https://m.agentalley.io/zip/0be59af6bb630f24a656/process-documentation.zip" -OutFile "$env:TEMP\process-documentation.zip"; Expand-Archive "$env:TEMP\process-documentation.zip" -DestinationPath "$HOME\.claude\skills" -Force

Claude.ai / desktopDownload the ZIP and upload it under Settings → Capabilities → Skills.

Codex, Cursor, other agentsPoint them at SKILL.md. The other files are plain text.

Connects with Agent Alley MCP · agentalley.io/mcp

Files included

SKILL.md2.8 KB

Read the files here

mohitagw15856/f6ca7931 file

SKILL.md2.8 KB

SKILL.md

Show the full text98 lines

process-documentation/SKILL.md98 lines · 2.8 KB

PreviewCode

Outline

RawView on GitHub

Process Documentation Skill

Produces clear, structured process documentation that someone new to a role can follow without needing to ask questions.

Required Inputs

Process name
Process description (rough notes are fine)
Who does this process (roles involved)
How often it runs (daily / weekly / monthly / event-triggered)
Tools involved
Known edge cases

Output Structure

Process: [Process Name]

Owner: [Role] | Frequency: [How often] | Estimated time: [Duration]

Purpose

[1-2 sentences. Why does this process exist? What breaks if it is not done?]

Scope

In scope: [What this covers] Out of scope: [What it does not cover]

Prerequisites

[Required access or information]
[Any dependency that must be completed first]

Roles and Responsibilities

Role	Responsibility
[Role 1]	[What they do]

Process Steps

Step 1: [Step name]

Who: [Role]
When: [Trigger or timing]
How: [Substeps numbered]
Output: [What exists at end of this step]
Tool: [System used]

[Continue for all steps]

Edge Cases and Exceptions

Situation	What to do	Who to contact
[Edge case]	[Action]	[Name/role]

Common Mistakes

[2-4 things people get wrong the first time]

Escalation Path

[Name/role] → [Next level] → [Final escalation]

Review

Next review due: [Date]

Quality Checks

Every step has a named role (not "someone" or "the team")
Edge cases and exceptions table is complete
Prerequisites are listed so someone new can prepare before starting
Escalation path is named (specific people or roles, not just "your manager")
Review date is set

Anti-Patterns

Do not write steps without specifying who is responsible for each — ownership must be explicit throughout
Do not omit the escalation path — every process must say what happens when something goes wrong
Do not document the ideal process if the real process differs — document reality, then note improvements separately
Do not skip edge cases and exceptions — they are where most process failures actually occur
Do not produce documentation without a review date — undated process docs quickly become incorrect

Example Trigger Phrases

"Document this process: [description]"
"Write a process guide for [workflow]"
"Map out how [process] works"

1	---
2	name: process-documentation
3	description: "Document any business process in a clear, structured format. Use when asked to document a process, write a process guide, create a workflow document, or map out how something works. Produces a complete process document with steps, roles, inputs, outputs, and edge cases."
4	---
5
6	# Process Documentation Skill
7
8	Produces clear, structured process documentation that someone new to a role can follow without needing to ask questions.
9
10	## Required Inputs
11	- Process name
12	- Process description (rough notes are fine)
13	- Who does this process (roles involved)
14	- How often it runs (daily / weekly / monthly / event-triggered)
15	- Tools involved
16	- Known edge cases
17
18	## Output Structure
19
20	---
21
22	# Process: [Process Name]
23	Owner: [Role] \| Frequency: [How often] \| Estimated time: [Duration]
24
25	---
26
27	### Purpose
28	[1-2 sentences. Why does this process exist? What breaks if it is not done?]
29
30	### Scope
31	In scope: [What this covers]
32	Out of scope: [What it does not cover]
33
34	### Prerequisites
35	- [ ] [Required access or information]
36	- [ ] [Any dependency that must be completed first]
37
38	---
39
40	### Roles and Responsibilities
41
42	\| Role \| Responsibility \|
43	\|---\|---\|
44	\| [Role 1] \| [What they do] \|
45
46	---
47
48	### Process Steps
49
50	Step 1: [Step name]
51	- Who: [Role]
52	- When: [Trigger or timing]
53	- How: [Substeps numbered]
54	- Output: [What exists at end of this step]
55	- Tool: [System used]
56
57	[Continue for all steps]
58
59	---
60
61	### Edge Cases and Exceptions
62
63	\| Situation \| What to do \| Who to contact \|
64	\|---\|---\|---\|
65	\| [Edge case] \| [Action] \| [Name/role] \|
66
67	---
68
69	### Common Mistakes
70	[2-4 things people get wrong the first time]
71
72	### Escalation Path
73	[Name/role] → [Next level] → [Final escalation]
74
75	### Review
76	Next review due: [Date]
77
78	## Quality Checks
79
80	- [ ] Every step has a named role (not "someone" or "the team")
81	- [ ] Edge cases and exceptions table is complete
82	- [ ] Prerequisites are listed so someone new can prepare before starting
83	- [ ] Escalation path is named (specific people or roles, not just "your manager")
84	- [ ] Review date is set
85
86	## Anti-Patterns
87
88	- [ ] Do not write steps without specifying who is responsible for each — ownership must be explicit throughout
89	- [ ] Do not omit the escalation path — every process must say what happens when something goes wrong
90	- [ ] Do not document the ideal process if the real process differs — document reality, then note improvements separately
91	- [ ] Do not skip edge cases and exceptions — they are where most process failures actually occur
92	- [ ] Do not produce documentation without a review date — undated process docs quickly become incorrect
93
94	## Example Trigger Phrases
95	- "Document this process: [description]"
96	- "Write a process guide for [workflow]"
97	- "Map out how [process] works"
98