process-doc
$
npx mdskill add anthropics/knowledge-work-plugins/process-docFormalizes undocumented business processes into structured SOPs, flowcharts, and RACI matrices for clarity and handoffs.
- Helps capture informal knowledge into formal documentation for audits or team transitions.
- Depends on user-provided descriptions or existing documents to guide the process.
- Asks targeted questions to gather necessary details for comprehensive output.
- Presents results as a detailed markdown document with sections like purpose and steps.
SKILL.md
.github/skills/process-docView on GitHub ↗
--- name: process-doc description: 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. argument-hint: "<process name or description>" --- # /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.
More from anthropics/knowledge-work-plugins
- accessibility-reviewRun a WCAG 2.1 AA accessibility audit on a design or page. Trigger with "audit accessibility", "check a11y", "is this accessible?", or when reviewing a design for color contrast, keyboard navigation, touch target size, or screen reader behavior before handoff.
- account-research"Research a company using Common Room data. Triggers on 'research [company]', 'tell me about [domain]', 'pull up signals for [account]', 'what's going on with [company]', or any account-level question."
- analyzeAnswer data questions -- from quick lookups to full analyses. Use when looking up a single metric, investigating what's driving a trend or drop, comparing segments over time, or preparing a formal data report for stakeholders.
- architectureCreate or evaluate an architecture decision record (ADR). Use when choosing between technologies (e.g., Kafka vs SQS), documenting a design decision with trade-offs and consequences, reviewing a system design proposal, or designing a new component from requirements and constraints.
- audit-supportSupport SOX 404 compliance with control testing methodology, sample selection, and documentation standards. Use when generating testing workpapers, selecting audit samples, classifying control deficiencies, or preparing for internal or external audits.
- brand-reviewReview content against your brand voice, style guide, and messaging pillars, flagging deviations by severity with specific before/after fixes. Use when checking a draft before it ships, when auditing copy for voice consistency and terminology, or when screening for unsubstantiated claims, missing disclaimers, and other legal flags.
- brand-voice-enforcement>
- briefGenerate contextual briefings for legal work — daily summary, topic research, or incident response. Use when starting your day and need a scan of legal-relevant items across email, calendar, and contracts, when researching a specific legal question across internal sources, or when a developing situation (data breach, litigation threat, regulatory inquiry) needs rapid context.
- build-dashboardBuild an interactive HTML dashboard with charts, filters, and tables. Use when creating an executive overview with KPI cards, turning query results into a shareable self-contained report, building a team monitoring snapshot, or needing multiple charts with filters in one browser-openable file.
- build-zoom-botBuild a Zoom meeting bot, recorder, or real-time media workflow. Use when joining meetings programmatically, processing live media or transcripts, or combining Meeting SDK, RTMS, and backend services.