Process Doc
Turn tacit how-we-actually-work knowledge into a complete SOP with RACI, flow, and edge cases for handoffs and audits.
Overview
process-doc is a journey-wide agent skill that formalizes how work actually gets done into SOPs with RACI and flowcharts—usable whenever a solo builder needs clarity before committing people or agents to a process.
Install
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill process-docWhat is this skill?
- Walk-through interview: name-only or pasted docs until a full SOP is produced
- RACI matrix per step with owner, review cadence, and scope boundaries
- ASCII or step-by-step process flow plus detailed per-step who/when/how/output
- Captures exceptions and edge cases—not only the happy path
- /process-doc command with argument-hint for process name or description
Adoption & trust: 1.5k installs on skills.sh; 19.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Critical work runs on tribal knowledge, so handoffs fail, audits stall, and nobody agrees who is accountable for each step.
Who is it for?
Formalizing recurring business or product ops—onboarding, releases, support tiers, or finance handoffs—when you need RACI and SOP language, not code.
Skip if: Generating application code, infra runbooks with executable commands only, or tasks where an already-approved technical implementation plan is the missing piece—use a planning skill instead.
When should I use this skill?
Formalizing a process in someone's head, building a RACI, writing an SOP for handoff or audit, or capturing exceptions of how work actually gets done.
What do I get? / Deliverables
You receive a dated process document with purpose, scope, RACI, flow, detailed steps, and edge cases ready to share or refine on a review cadence.
- Process document markdown with RACI, flow, detailed steps, purpose, and scope
- Owner, last updated, and review cadence metadata block
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Before building a big feature, document the customer onboarding process so scope reflects real operational steps.
Write the repeatable launch checklist with owners so each channel push follows the same SOP.
Capture tier-1 vs tier-2 support flows with consulted and informed roles for a future VA.
Refresh quarterly review cadence on billing or incident response SOPs after process drift.
Map how you currently validate ideas manually so you can see bottlenecks before automating.
How it compares
Produces human-readable SOPs and RACI matrices, not agent implementation plans or MCP-connected automation.
Common Questions / FAQ
Who is process-doc for?
Solo founders and indie operators who need documented processes for contractors, small teams, or compliance-style clarity without hiring a business analyst.
When should I use process-doc?
During Validate when scoping who does what; at Launch for distribution checklists; in Grow for support and lifecycle handoffs; and in Operate when iterating SOPs, RACI, or audit-ready steps.
Is process-doc safe to install?
It is primarily conversational documentation output; review the Security Audits panel on this Prism page and CONNECTORS.md if your process references connected tools.
SKILL.md
READMESKILL.md - Process Doc
# /process-doc > If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md). 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] ``` ## 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.