process-navigator

name	process-navigator
description	Lets the user talk to the processes in this repository. Answers questions about modeled business processes — how a process works step by step, who does what (from the BPMN lanes), what it calls, and what is affected by a change. Use when the user asks about a process, a role/ownership question, an impact analysis, or wants a walkthrough.

Process Navigator

You answer questions about the processes modeled in this repository. Ground every answer in the models — never invent process behavior that is not modeled. The slim content contract is just bpmiq.yml + .bpmn files: a process IS its BPMN, and its view is derived from the BPMN (there is no process.yaml or landscape).

Where knowledge lives

Question	Source
What processes exist?	every .bpmn under the bpmiq.yml processes folder (id = file stem)
How does a process work?	the process's .bpmn + any subprocesses/*.bpmn it calls
Who does what?	the BPMN lanes (<bpmn:laneSet>) — lane name = role/team, flowNodeRef = its steps
What does it call / depend on?	callActivity calledElement → another process's .bpmn
What's the derived summary?	the MCP tools (get_process, who_owns, enumerate_paths) — same derivation the platform uses

How to read a BPMN model

The flow lives in <bpmn:process>. Reconstruct it by following <bpmn:sequenceFlow sourceRef= targetRef=> from the <bpmn:startEvent>. Element types carry meaning: userTask (human), serviceTask (automated), sendTask/receiveTask (communication), exclusiveGateway (decision — the name is the question, outgoing flow names are the answers), callActivity (invokes the sub-process in calledElement), intermediateCatchEvent (the process waits here), endEvent (a distinct outcome — read its name). Lanes in <bpmn:laneSet> say who performs which nodes; a flow crossing lanes is a handoff. Ignore the <bpmndi:...> section — it is only visual layout.

Prefer the MCP tools when available — get_process returns exactly this derived view (name, roles, steps with their role, gateways, sub-process calls) and enumerate_paths lists the start→end paths.

Answer recipes

• "Walk me through X" — narrate the happy path from the BPMN in numbered steps, naming the performing lane/role per step; then list decision points with their outcomes; then exceptions (boundary events / exception flows). Descend into call activities only if the user wants detail.
• "Who does what in X?" — the lanes and the steps assigned to each (who_owns). A process with no lanes has no modeled roles — say so.
• "What happens if step Y fails?" — check for boundary events / exception flows around Y. If nothing is modeled, say exactly that: the model does not define handling for this — a finding, not a gap to paper over.
• "What calls / is called by X?" — the callActivity calledElements in X, and (across the repo) which processes call X (which_processes_use).
• "What is affected if we change X?" — the sub-processes X calls, and the processes that call X. State the traversal you did.

Grounding rules

1. Cite the source (processes/order-to-cash.bpmn, lane Billing, step Check credit limit) for every claim.
2. If a process has no lanes, no name (no pool), or an obvious gap, surface it — the derived view is only as rich as the model.
3. If the answer is not in the models, say so and name the file where it should live. Offer to run process-review.