---
name: process-map-from-discovery
description: Convert discovery inputs into process maps and process evolution visuals. Use when Codex is asked to turn Teams transcripts, cleaned meeting notes, requirements documentation, or similar discovery artifacts into L0-L2 business process maps, swimlane maps, BPMN-style maps, current-state/as-is maps, target-state/to-be maps, gap/change views, or future-state roadmap/process evolution maps. Default outputs are Mermaid diagrams and editable native-shape PowerPoint drafts; use this skill for draft mapping artifacts, not narrative requirements analysis.
---

# Process Map From Discovery

## Overview

Transform discovery content into draft process maps that can be reviewed, refined, and moved into PowerPoint, Lucidchart, or other visualization tools. Build a canonical process-map model first, then render Mermaid and, when requested, editable PowerPoint shapes from the same model.

## Core Workflow

1. Inspect the source artifacts and identify the requested map type, process level, and state:
   - Level: L0, L1, or L2.
   - Type: consulting boxes/arrows, swimlane, BPMN-style, or future-state roadmap/process evolution.
   - State: current/as-is, target/to-be, or gap/change.
   - Swimlane type when `map_type` is `swimlane`: `persona`, `system`, or `mixed`.
   - If the user requested a swimlane map and did not specify the swimlane type, ask before generating the final Mermaid or PowerPoint output.
2. Extract only map-relevant information:
   - Activities, decisions, events, handoffs, systems, roles/lanes, inputs/outputs, integrations, and start/end points.
   - Preserve uncertainty as explicit assumptions or TODO labels inside the model, not as long narrative.
3. Create a canonical model using `references/process-map-model.md`.
4. Validate the process logic using `references/process-logic-validation.md` before rendering:
   - Confirm the primary path, all alternate paths, starts/ends, decisions, branch labels, loopbacks/rework, handoffs, and non-progressive associations.
   - Add explicit `start`, `activity`/action, `decision`, and `end` nodes. Do not let a branch stop at an action node.
   - Use arrows as the authoritative flow signal. Do not rely on horizontal placement alone to imply sequence.
   - Enforce left-to-right progression for sequential steps performed in the same swimlane.
   - Allow cross-lane handoffs to align vertically or near-vertically when that improves readability.
   - Apply `references/process-flow-layout-policy.md` for persistent handoffs, one-step swimlane excursions, branch rejoins, and loopbacks.
5. Render Mermaid using `scripts/process_map_to_mermaid.py` or by following `references/mermaid-patterns.md`.
6. Render editable PowerPoint when requested using `scripts/process_map_to_pptx.py`.
7. Return the requested artifacts and include concise validation notes: source coverage, ambiguous steps, and any rendering limitations.

## Map Selection

- Use consulting boxes/arrows for L0/L1 executive or business-review maps when the source emphasizes phases, high-level activities, or operating model flow.
- Use swimlanes when roles, teams, systems, or handoffs matter.
- For swimlanes, ask whether the lanes should represent personas/roles/teams or systems/applications before rendering the end product unless the answer is already explicit from the request.
- Use `lane_type: "persona"` when lanes are people, roles, teams, departments, customers, partners, or operational owners.
- Use `lane_type: "system"` when lanes are applications, platforms, portals, integrations, data stores, automation services, or external systems.
- Use `lane_type: "mixed"` only when the user explicitly wants both persona and system lanes in one map; otherwise prefer separate persona and system views.
- Use BPMN-style maps when the source contains explicit events, gateways/decisions, alternate paths, exceptions, or system/user tasks.
- Use process evolution/roadmap maps when the source contrasts current state, interim releases, future state, or change waves.
- For Service Blueprint or Customer Journey outputs, confirm the user explicitly requested that format, then create a separate format-specific structure rather than forcing it into a standard process map.

## Output Defaults

- Default to Mermaid plus the canonical model unless the user asks for PowerPoint.
- Make PowerPoint output editable native shapes, not screenshots, whenever the map is generated by this skill.
- Treat PowerPoint as the fidelity render for screenshot-like layouts because it honors explicit coordinates and routed connectors.
- Treat Mermaid as a structured review/import render. Use ELK-configured flowchart output by default; use `swimlane-beta` or `block` only when the user or destination renderer benefits from those Mermaid formats.
- Use Mermaid as the Lucidchart handoff format unless the user asks for a different Lucidchart import path.
- Keep outputs draft-oriented. Do not add client-polish narrative, business analysis, requirements commentary, or RAID unless the user asks.
- Prefer one map per coherent process/state. Split large processes into an L0 overview and one or more L1/L2 detail maps instead of making an unreadable single diagram.
- Use connector arrows for progressive process flow. Use dashed/no-arrow connectors only for notes, references, data associations, or other non-progressive relationships.
- Use real PowerPoint connectors attached to source and target shapes by default. Use segmented routed connectors only for explicit multi-waypoint paths or fallback.
- Use lane-aware connector ports: same-lane flow attaches right-to-left; cross-lane flow attaches through top/bottom ports based on lane direction.

## PowerPoint Guidance

Use PowerPoint for editable draft materials. The helper script creates native rectangles, diamonds, terminators, swimlane bands, connectors, and simple notes from the canonical model.

For high-value client polish, produce the editable draft and recommend a separate design pass. Do not substitute a static Mermaid-rendered image unless the user explicitly asks for a quick visual only.

## Resource Routing

- Read `references/process-map-model.md` before creating a model or using either script.
- Read `references/process-logic-validation.md` before rendering any map with decisions, loopbacks, rework, cross-lane handoffs, or ambiguous sequencing.
- Read `references/process-flow-layout-policy.md` before rendering swimlane maps with cross-lane handoffs, one-step lane excursions, decision branches, branch rejoins, or loopbacks.
- Read `references/mermaid-patterns.md` when generating Mermaid manually or troubleshooting output.
- Read `references/pptx-shape-guidance.md` before changing PowerPoint layout conventions or script behavior.
- Use `scripts/process_map_to_mermaid.py` to convert model JSON to Mermaid.
- Use `scripts/process_map_to_pptx.py` to convert model JSON to editable PowerPoint.

## Expected Commands

```powershell
python .\scripts\process_map_to_mermaid.py .\process-map.json --output .\process-map.mmd
python .\scripts\process_map_to_pptx.py .\process-map.json --output .\process-map.pptx
```

## Quality Bar

- Every map must have a clear start and end, or explicitly mark missing starts/ends.
- Every terminal path must end in an `end` node. If the source does not name the ending event, create a concise inferred end node with `confidence: low`.
- Every decision must have at least two outgoing process branches unless the model explicitly marks it as unresolved.
- Every decision branch must show a label when the source supports it; if unsupported, use a concise TODO or inferred label with low confidence.
- Every loopback or rework path must be explicitly typed as a loopback/rework edge and labeled with the condition that sends work backward.
- Same-lane sequential steps must progress left-to-right unless the edge is explicitly a loopback/rework path.
- Cross-lane handoffs may be vertically aligned; the arrow, label, and lane ownership communicate progression.
- One-step swimlane excursions must advance horizontally as well as vertically so the temporary step does not stack directly above or below the surrounding process steps.
- Branch rejoins must be placed to the right of all contributing branch endpoints.
- Every swimlane map must assign each activity to a lane.
- Current/as-is and target/to-be maps must be separate diagrams unless the user asks for a combined gap/change view.
- Use stable IDs in the model so Mermaid, PPT, and later tools can reference the same elements.
- Every swimlane model must set `lane_type` to `persona`, `system`, or `mixed` before rendering.
- If source material is ambiguous, mark the model item with `confidence: low` and a short `note`.