AgentAlley
Submit

Process Documentation Skill

Document any business process in a clear, structured format.

Process Documentation Skill — The Skill Playground: pick the Executive Update skill, fill in a few notes, hit run, and watch a structured executive… (from the mohitagw15856/pm-claude-skills README)

From the mohitagw15856/pm-claude-skills README — shows the whole collection, not only this skill. · view on GitHub

How to use it

Claude Code
  1. Run the line below. It pulls the whole folder into ~/.claude/skills/process-documentation.
  2. Describe your job in plain words. Claude Code follows the skill from there.
Claude Code — installs the whole folder, not just SKILL.md
npx degit mohitagw15856/pm-claude-skills/skills/process-documentation#main ~/.claude/skills/process-documentation

For one project only, change the path to .claude/skills/process-documentation.

Claude (web or desktop app)
  1. On this page open ⋯ → Download .md.
  2. Save it as SKILL.md in a folder, zip the folder, then Customize → Skills → + → Create skill → Upload a skill.
  3. Pick the file and Save. Claude shows the name and description and runs a security scan.
  4. Check the skill is switched on.
  5. Start a new chat and describe your job in plain words. The AI follows the skill from there.
ChatGPT or another app
  1. ChatGPT: make a Project and paste it into Instructions.
  2. Neither? Paste it at the top of a new chat — it works for that chat.
Not working?
  • Check which app you pasted it into — the steps above name the right one.
  • Some skills need the paid tier of Claude or ChatGPT.
Step-by-step guide with screenshots · Ask in the forum

Paste into Claude, ChatGPT or Cursor.

Source of Process Documentation Skill

Show the full text98 lines
process-documentation/SKILL.md98 lines · 2.8 KB
Outline
RawView on GitHub
namedescription
process-documentationDocument 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

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---
2name: process-documentation
3description: "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 
8Produces 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
76Next 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 

Discussion

Alternatives

Also in Developer docsSee all 533 in Development →
Github repository analysis and enhancementAct as a GitHub Repository Analyst to perform in-depth analysis and suggest improvements for repository structure, documentation, code quality, and community engagement.Coding · CC0-1.0Multi-Audience Application Discovery & Documentation PromptA prompt designed to analyze a codebase and generate comprehensive Markdown documentation tailored for executive, technical, product, and business audiences. It guides an AI to extract high-level system purpose, architecture, key components, workflows, product features, business domains, and limitations, producing an onboarding and discovery document suitable for both technical and non-technical stakeholders.Coding · CC0-1.0Documentation and adrsRecords decisions and documentation. Use when you need to document an architecture decision (ADR) or the reasoning behind a design choice, when changing public APIs, shipping features, or when you need to record context that future engineers and agents will need to understand the codebase.Coding · MITTreatment-Plan DocumentationFormat and structurally validate local treatment-plan documentation after clinical decisions have already been supplied and verified by authorized licensed professionals. Use for source traceability, clinician-authored intervention records, goals and checkpoints, shared-decision records, reconciliation handoffs, and release gates—not for clinical decision-making.Science · MIT

Browse more free Claude skills or everything in Development.