process-documentation

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.

Published by mohitagw15856 ↗mohitagw15856/pm-claude-skills

Try your first task

Start a fresh conversation. Replace the highlighted placeholders.

Use process-documentation to create an onboarding-ready process guide for [process name] from [process notes], with explicit role-owned steps, inputs, outputs, prerequisites, exceptions, escalation path, and review date.

Required inputs

[process name]
[process notes]

User-approved starter prompt based on a pinned source version; check current skill requirements before running. Task evidence ↗

SKILL.md

name: process-documentationdescription: "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

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"