What this skill does
Produces a structured process map with swim lanes, task nodes, decision diamonds, and handoff arrows. Output is in Mermaid flowchart notation (renderable in GitHub, VS Code, Confluence, and Miro) or BPMN-lite text when a formal notation is required. It also generates a companion process narrative for documentation.
When to use it
- User asks to "map a process", "document a workflow", or "draw an AS-IS/TO-BE diagram".
- User needs to identify bottlenecks, redundancies, or handoff gaps in an existing process.
- User is designing a new process and needs a visual spec before implementation.
- User wants to feed the output into a
miro-board or include it in a requirements-document.
Key concepts
AS-IS vs. TO-BE
|
AS-IS |
TO-BE |
| Purpose |
Document what currently happens, including workarounds and pain points |
Define the improved or target process |
| Annotation |
Mark pain points (⚠), manual steps (M), and system steps (S) |
Mark new capabilities (NEW) and removed steps (REMOVED) |
| Output |
Evidence base for improvement |
Specification for change |
Process map elements
| Element |
Notation |
Mermaid syntax |
| Start / End |
Circle |
([Start]) / ([End]) |
| Task / Activity |
Rectangle |
[Task name] |
| Decision |
Diamond |
{Decision?} |
| Sub-process |
Double border |
[[Sub-process]] |
| Data store |
Cylinder |
[(Data store)] |
| Swim lane |
Subgraph |
subgraph Actor |
Swim lanes
Each actor (person, role, system, or external party) gets its own swim lane. Handoffs occur when an arrow crosses lane boundaries.
Instructions
Identify the process type. AS-IS, TO-BE, or both (comparison).
Name the process. Short, active-verb label (e.g., "Order fulfilment", "User onboarding", "Incident response").
Identify actors. List all roles, systems, and external parties involved. Each becomes a swim lane.
Elicit process steps. From the user's description, identify:
- Tasks (what is done)
- Decisions (yes/no or multi-path branch points)
- Handoffs (step passes from one actor to another)
- Start and end events
Map pain points (AS-IS only). Note any steps described as slow, manual, error-prone, or unclear. Annotate them in the diagram.
Identify improvements (TO-BE only). Mark new steps, automated replacements, and removed steps.
Render the Mermaid diagram following the format below.
Write the process narrative — a numbered step-by-step description matching the diagram.
Output format
## Process map: [Process name] ([AS-IS / TO-BE])
```mermaid
flowchart TD
subgraph Actor1["[Swim lane 1 label]"]
A([Start]) --> B[Task 1]
B --> C{Decision?}
end
subgraph Actor2["[Swim lane 2 label]"]
C -->|Yes| D[Task 2]
C -->|No| E[Task 3]
D --> F[Task 4]
E --> F
end
subgraph System["[System label]"]
F --> G[(Data store)]
G --> H([End])
end
```
### Pain points (AS-IS) / Changes (TO-BE)
| Step | Issue / Change | Severity / Type |
| --- | --- | --- |
| [Task name] | [Description] | Pain point / New / Removed / Automated |
### Process narrative
1. **[Actor]** — [Step description].
2. **[Actor]** — [Step description]. If [condition], go to step N.
3. ...
### Handoff summary
| From | To | Trigger |
| --- | --- | --- |
| [Actor] | [Actor] | [What causes the handoff] |
Examples
Example 1 — AS-IS order fulfilment
Input: "Map our current order fulfilment process. Customer places order on website, ops team manually checks stock, emails supplier if out of stock, warehouse picks and packs, courier collects."
Expected output: Mermaid diagram with swim lanes for Customer, Ops, Warehouse, Supplier, Courier. Manual email step annotated as pain point. Process narrative with handoff summary.
Example 2 — TO-BE incident response
Input: "Document the new incident response process after we add PagerDuty. Alert fires → PagerDuty pages on-call → engineer acknowledges → triages → resolves or escalates → post-mortem."
Expected output: TO-BE diagram with System (monitoring), PagerDuty, On-call Engineer swim lanes. Steps marked NEW where PagerDuty replaces manual paging. Post-mortem step annotated as new capability.
Example 3 — AS-IS and TO-BE comparison
Input: User provides both current and target process descriptions.
Expected output: Two Mermaid diagrams side by side, a change summary table listing added, removed, and modified steps, and a narrative explaining the key improvements.
Notes
- Keep swim lane labels short — they appear as diagram headers.
- Mermaid flowchart direction:
TD (top-down) for most processes; LR (left-right) for linear pipelines.
- If the process has more than 15 steps, consider splitting it into sub-processes and mapping each separately.
- For formal BPMN output (e.g., for Signavio, Camunda, or Visio import), note that Mermaid is BPMN-inspired but not BPMN-compliant. Offer to produce a BPMN XML skeleton if the user needs a tool-importable format.
- This skill pairs directly with
gap-analysis (map AS-IS first, then identify gaps to reach TO-BE) and miro-board (Mermaid diagrams can be embedded in Miro frames).
1---2name: process-map3description: Produces a structured process map with swim lanes, task nodes, decision diamonds, and handoff arrows. Output is in **Mermaid** flowchart notation (renderable in GitHub, VS Code, Confluence, and Miro) or **BPMN-lite** text when a formal notation is required.4---56## What this skill does78Produces a structured process map with swim lanes, task nodes, decision diamonds, and handoff arrows. Output is in **Mermaid** flowchart notation (renderable in GitHub, VS Code, Confluence, and Miro) or **BPMN-lite** text when a formal notation is required. It also generates a companion process narrative for documentation.910## When to use it1112- User asks to "map a process", "document a workflow", or "draw an AS-IS/TO-BE diagram".13- User needs to identify bottlenecks, redundancies, or handoff gaps in an existing process.14- User is designing a new process and needs a visual spec before implementation.15- User wants to feed the output into a `miro-board` or include it in a `requirements-document`.1617## Key concepts1819### AS-IS vs. TO-BE2021| | AS-IS | TO-BE |22| --- | --- | --- |23| **Purpose** | Document what currently happens, including workarounds and pain points | Define the improved or target process |24| **Annotation** | Mark pain points (⚠), manual steps (M), and system steps (S) | Mark new capabilities (NEW) and removed steps (REMOVED) |25| **Output** | Evidence base for improvement | Specification for change |2627### Process map elements2829| Element | Notation | Mermaid syntax |30| --- | --- | --- |31| Start / End | Circle | `([Start])` / `([End])` |32| Task / Activity | Rectangle | `[Task name]` |33| Decision | Diamond | `{Decision?}` |34| Sub-process | Double border | `[[Sub-process]]` |35| Data store | Cylinder | `[(Data store)]` |36| Swim lane | Subgraph | `subgraph Actor` |3738### Swim lanes3940Each actor (person, role, system, or external party) gets its own swim lane. Handoffs occur when an arrow crosses lane boundaries.4142## Instructions43441. **Identify the process type.** AS-IS, TO-BE, or both (comparison).45462. **Name the process.** Short, active-verb label (e.g., "Order fulfilment", "User onboarding", "Incident response").47483. **Identify actors.** List all roles, systems, and external parties involved. Each becomes a swim lane.49504. **Elicit process steps.** From the user's description, identify:51 - Tasks (what is done)52 - Decisions (yes/no or multi-path branch points)53 - Handoffs (step passes from one actor to another)54 - Start and end events55565. **Map pain points (AS-IS only).** Note any steps described as slow, manual, error-prone, or unclear. Annotate them in the diagram.57586. **Identify improvements (TO-BE only).** Mark new steps, automated replacements, and removed steps.59607. **Render the Mermaid diagram** following the format below.61628. **Write the process narrative** — a numbered step-by-step description matching the diagram.6364## Output format6566````markdown67## Process map: [Process name] ([AS-IS / TO-BE])6869```mermaid70flowchart TD71 subgraph Actor1["[Swim lane 1 label]"]72 A([Start]) --> B[Task 1]73 B --> C{Decision?}74 end7576 subgraph Actor2["[Swim lane 2 label]"]77 C -->|Yes| D[Task 2]78 C -->|No| E[Task 3]79 D --> F[Task 4]80 E --> F81 end8283 subgraph System["[System label]"]84 F --> G[(Data store)]85 G --> H([End])86 end87```8889### Pain points (AS-IS) / Changes (TO-BE)9091| Step | Issue / Change | Severity / Type |92| --- | --- | --- |93| [Task name] | [Description] | Pain point / New / Removed / Automated |9495### Process narrative96971. **[Actor]** — [Step description].982. **[Actor]** — [Step description]. If [condition], go to step N.993. ...100101### Handoff summary102103| From | To | Trigger |104| --- | --- | --- |105| [Actor] | [Actor] | [What causes the handoff] |106````107108## Examples109110### Example 1 — AS-IS order fulfilment111112**Input:** "Map our current order fulfilment process. Customer places order on website, ops team manually checks stock, emails supplier if out of stock, warehouse picks and packs, courier collects."113114**Expected output:** Mermaid diagram with swim lanes for Customer, Ops, Warehouse, Supplier, Courier. Manual email step annotated as pain point. Process narrative with handoff summary.115116### Example 2 — TO-BE incident response117118**Input:** "Document the new incident response process after we add PagerDuty. Alert fires → PagerDuty pages on-call → engineer acknowledges → triages → resolves or escalates → post-mortem."119120**Expected output:** TO-BE diagram with System (monitoring), PagerDuty, On-call Engineer swim lanes. Steps marked NEW where PagerDuty replaces manual paging. Post-mortem step annotated as new capability.121122### Example 3 — AS-IS and TO-BE comparison123124**Input:** User provides both current and target process descriptions.125126**Expected output:** Two Mermaid diagrams side by side, a change summary table listing added, removed, and modified steps, and a narrative explaining the key improvements.127128## Notes129130- Keep swim lane labels short — they appear as diagram headers.131- Mermaid flowchart direction: `TD` (top-down) for most processes; `LR` (left-right) for linear pipelines.132- If the process has more than 15 steps, consider splitting it into sub-processes and mapping each separately.133- For formal BPMN output (e.g., for Signavio, Camunda, or Visio import), note that Mermaid is BPMN-inspired but not BPMN-compliant. Offer to produce a BPMN XML skeleton if the user needs a tool-importable format.134- This skill pairs directly with `gap-analysis` (map AS-IS first, then identify gaps to reach TO-BE) and `miro-board` (Mermaid diagrams can be embedded in Miro frames).