business-process

Business Process

Create or update BPMN 2.0 business process models in docs/processes/. A business process is the map of the business above the use cases: it connects user goals that different roles reach at different times into one flow from a business event to a business outcome. Every activity of the process is one use case, every lane is a role, and every path from the start to an end event is one end-to-end journey that /test-case BP-XXX turns into a test case.

The process needs the use cases, not their specifications: the use case diagram names every activity and its actor, and the requirements say how the activities connect. A process can therefore be modeled right after /use-case-diagram, before or alongside /use-case-spec.

Inputs

$ARGUMENTS selects the scope. Text after the arguments that says where the project keeps its artifacts (e.g. "The BPMN process models live under docs/bpmn/") replaces the default folders named in this skill.

• No argument — derive the processes from the requirements and the use case diagram. Read the inputs below, propose the list of business processes (id, name, trigger, outcome, the use cases each one connects, and which existing models it updates), and ask the user to confirm the list before writing any file.
• BP-XXX (e.g. /business-process BP-001) — update that process only: docs/processes/BP-XXX-*.bpmn. Stop and tell the user when no such file exists.
• A process name (e.g. /business-process "Book Loan") — create one new process with the next free id, or update the existing one with that name.

Read, in this order:

• docs/requirements.md — the functional requirements say which business flows exist, what triggers and ends them, and which decisions lead from one use case to the next; their ids go into the process documentation.
• docs/use_cases.puml — the activities. Every use case of the diagram is a candidate activity; the actor associated with it is its lane. This is the only use case input the skill needs. When it is a @startuml Modules overview, the use cases are in the module diagrams docs/use_cases/*/use_cases.puml.
• docs/use_cases/**/UC-*.md only when they exist — never required. A specification's trigger, preconditions, postconditions, and alternative flows can sharpen the order and the decisions; where it contradicts the diagram or the requirements, report it and follow the diagram.
• docs/glossary.md when it exists — name events, gateways, and lanes with its terms, never with a synonym from its Avoid column.
• docs/processes/*.bpmn — the existing models, so you never create a second model of the same process.