Purpose
Take a loosely described business process and turn it into a rigorous, machine-legible breakdown — every step mapped to its inputs, outputs, owner, and system of record, with dependencies, edge cases, and failure modes made explicit. Solves the problem of tribal knowledge and undocumented workflows that resist automation, handoff, or reliable execution.
When to Use
Invoke this skill when the user asks to:
- Document or map out an existing business process end-to-end
- Prepare a workflow for automation, RPA, or AI agent integration
- Identify where a process breaks, stalls, or produces errors
- Onboard a new team member to a complex operational workflow
- Find handoff gaps, ownership ambiguity, or single points of failure
- Standardize an ad-hoc process into a repeatable SOP
Inputs Required
Before starting, collect:
- Process name: What the process is called internally
- Process description: A narrative of how it currently runs, start to finish
- Trigger: What kicks the process off (event, request, schedule, threshold)
- End state: What "done" looks like — the completed outcome
- Systems/tools involved: Software, spreadsheets, forms, or platforms touched
- Roles involved: Who does what (titles or functions, not names)
- Known pain points: Any steps that currently fail, slow down, or cause rework
If roles or systems are only partially described, infer likely owners and systems from the narrative and flag each inference explicitly as an assumption.
Instructions
Step 1: Establish Process Boundaries
Pin down the scope before decomposing.
- Trigger event: The single condition that starts the process — name it precisely
- End state: The concrete deliverable or state change that marks completion
- In-scope vs. out-of-scope: Note adjacent processes that feed in or receive output but are not being decomposed here
- Cadence: One-off, on-demand, or recurring (and frequency if recurring)
Step 2: Sequence the Steps
Break the process into discrete, atomic steps in execution order. Each step is a single action performed by a single owner. For every step, capture:
- Step number and name: Verb-first (e.g., "Validate customer PO against contract terms")
- Owner: The role responsible for executing it
- Inputs: What must exist before this step can run (data, documents, approvals, prior outputs)
- Action: What the owner actually does
- Outputs: What the step produces and passes forward
- System of record: Where the output is created, stored, or updated
Split any step that contains "and" between two distinct actions or two distinct owners.
Step 3: Map Dependencies
Make the connective tissue explicit.
- Sequential dependencies: Steps that cannot start until a prior step completes
- Parallel steps: Steps that can run simultaneously
- External dependencies: Waits on other teams, vendors, customers, or systems outside the process owner's control
- Data dependencies: Steps that require a specific field, record, or document to be accurate — note the upstream source
Flag every handoff between roles as a dependency, since handoffs are the most common breakage point.
Step 4: Surface Decision Points
Identify every branch where the process can go more than one way. For each decision point:
- Condition: The question being evaluated (e.g., "Is order value above $10K?")
- Branches: Each possible outcome and the path it triggers
- Decision owner: Who or what makes the call (person, rule, or system)
- Ambiguity risk: Note branches where the decision criteria are subjective or undocumented
Step 5: Enumerate Edge Cases
List the non-standard inputs and situations the process must handle. Work through these categories:
- Missing or incomplete input: Required data or documents absent
- Out-of-range values: Inputs outside expected bounds (amounts, dates, quantities)
- Duplicate or conflicting input: Same request submitted twice, or contradictory data
- Timing exceptions: Late arrivals, expirations, off-hours triggers
- Unusual actor: A new role, external party, or exception approver enters the flow
For each edge case, note whether the current process handles it explicitly, handles it informally, or has no defined path (the last is a gap).
Step 6: Identify Failure Modes
For each step and handoff, ask: how does this break? For every failure mode:
- Failure description: What goes wrong
- Trigger: The condition that causes it
- Impact: Downstream consequence (rework, delay, compliance risk, customer impact)
- Likelihood: High / Medium / Low based on the described pain points
- Detection: How (or whether) the failure is currently caught
- Mitigation: The control or fix that would prevent or catch it
Prioritize failure modes with high impact and weak detection — these are silent risks.
Step 7: Flag Automation & AI Candidates
Mark each step for automation potential.
- Fully automatable: Rule-based, high-volume, structured inputs → RPA or script
- AI-assisted: Requires judgment on unstructured input (classification, extraction, drafting) → LLM/agent candidate
- Human-required: Genuine judgment, negotiation, or accountability that should stay human
- Automation blocker: Note what prevents automation today (data quality, system access, exception rate)
Output Format
- Structure: A step table as the spine, followed by dedicated sections for dependencies, decision points, edge cases, and failure modes
- Length: 900–1,400 words depending on process complexity
- Format: Structured document — step breakdown as a table; dependencies, decisions, edge cases, and failure modes as labeled lists or tables
- Sections: Process Boundaries → Step Breakdown (table: #, Step, Owner, Inputs, Outputs, System) → Dependency Map → Decision Points → Edge Cases → Failure Modes (table: Failure, Trigger, Impact, Likelihood, Detection, Mitigation) → Automation & AI Candidates
- Tone: Analytical and precise — a business analyst's working document, not a narrative summary. No filler, no hedging.
Quality Checklist
Before delivering output, verify:
- [ ] Every step has all six attributes filled in (owner, inputs, action, outputs, system) — no blank cells
- [ ] Every handoff between roles is listed as a dependency
- [ ] Each decision point lists all branches, not just the primary path
- [ ] At least one edge case is identified per input-receiving step, and gaps (no defined path) are explicitly labeled
- [ ] Every failure mode includes impact, likelihood, and detection — not just a description
- [ ] All inferred owners or systems are flagged as assumptions, not stated as fact
Notes
- The most valuable output is usually the failure-mode and edge-case sections — these are what tribal knowledge hides and what breaks in automation.
- Handoffs between roles and systems account for the majority of process failures; scrutinize them harder than in-role steps.
- If the process description is a single paragraph with no role detail, ask one clarifying question: "Who touches this from trigger to completion, and where does each person do their part?"
- A step that can't be assigned a single clear owner is itself a finding — flag it rather than guessing.
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills