review-process

name	review-process
user-invocable	false
allowed-tools	Read, Glob, Grep
description	Audit a Zeebe BPMN process and its glue-code (workers, process adapter, tests) for consistency and coverage, producing a structured report written to `.claude/temp/`. Use when the user asks to "review the newsletter process", "audit a BPMN process", "check process consistency", or "use the review-process subagent". Checks task-type coverage, message coverage, ProcessApi consistency, variable coverage, test coverage, and BPMN styleguide compliance.

Skill: review-process

Review a BPMN process model and its glue-code for consistency, coverage, and correctness. Produce a structured consistency report and write it to a file at the end.

IMPORTANT

• You are a read-only agent, only reviewing processes.
• Never write anything to a source-file - other than your report
• Write your output to the temp-folder .claude/temp in a file review-<process>.md
• If the bpmn-model to review could not be found ask the user to provide a concrete path

Instructions

To perform the review of a process, execute the following steps in order:

Step 1 – Locate and read the BPMN file

Search for the .bpmn file in src/main/resources/bpmn/ matching the process name given. If you cannot find a file, ask the user to provide a path to it.

If you found a matching file, read the file and extract:

• Service task types (zeebe:taskDefinition type attribute values)
• Message names (<bpmn:message name="..."> values)
• Process variables referenced in expressions or I/O mappings
• Process ID (<bpmn:process id="...">)
• Element IDs for all service tasks, events, and gateways
• Timer definitions and boundary event types

Step 1b – Read the BPMN styleguide

Read docs/bpmn-styleguide/styleguide.md. Extract the conventions for:

• Element ID format: Type_Name in CamelCase (e.g. serviceTask_SendWelcomeMail)
• Message ID format: <serviceName>.<state> — both parts CamelCase (e.g. newsletter.subscriptionConfirmed)
• Type ID format: <serviceName>.<elementIdWithoutTypePrefix> — both parts CamelCase (e.g. newsletter.sendWelcomeMail)
• Naming rules: tasks (verb + noun), events (noun + past tense), gateways (short question)

If the styleguide does not exist, quit with an according error-message

Step 2 – Read the ProcessApi file

Locate the ProcessApi file (typically in adapter/process/). Read and extract:

• PROCESS_ID constant
• All TaskTypes.* constants
• All Messages.* constants
• All Variables.* constants
• All Elements.* constants

If you cannot find a ProcessApi, ask the user to provide a path.

Step 3 – Discover and read workers and tests

Locate all files in adapter/inbound/zeebe/. For each worker, identify:

• The @JobWorker(type = ...) value and which ProcessApi constant it references
• The @Variable parameters used

If none are found this can be a valid output either. However, mark this in your final report, in case the processModel defines serviceTasks. In this case, it should be reviewed by the user.

Step 4 – Read the process out-adapter and tests

Locate the process out-adapter in adapter/outbound/zeebe/. For each public method, identify:

• Whether it calls startProcess or sendMessage
• Which processId and messageName constants it uses

If none are found this can be a valid output either. However, mark this in your final report, in case the processModel defines messages. In this case, it should be reviewed by the user.

Step 5 – Read the process test

Locate the process integration test (typically in test/.../adapter/process/). Identify:

• Which process paths are tested (happy path, timer expiry, abort, etc.)
• Which elements are asserted with hasCompletedElement

Step 6 – Produce the consistency report

Output a structured report with these sections:

Task Type Coverage: For each service task in the BPMN, report whether a worker exists. Flag BPMN tasks without a worker and workers without a BPMN task.

Message Coverage: For each message in the BPMN, report whether the process adapter has a corresponding method. Flag gaps.

ProcessApi Consistency: Compare ProcessApi constants against actual BPMN values. Flag mismatches and warn about raw string literals in workers or adapters.

Variable Coverage: List variables used in workers and adapters. Verify they appear in Variables.* in the ProcessApi.

Test Coverage: For each identified process path, report whether a test exists that covers it. Also report whether each worker and process-adapter are covered as well

Styleguide Compliance: Check the BPMN model against the conventions loaded in Step 1b:

• For each service task, event, and gateway: verify the element ID matches the Type_Name CamelCase pattern
• For each message: verify the message name matches the <serviceName>.<state> CamelCase pattern
• For each task type (job type): verify it matches the <serviceName>.<elementIdWithoutTypePrefix> pattern
• Flag element IDs that use auto-generated values (e.g. Activity_0xf83kz) or that deviate from the convention
• Flag task/event names that do not follow verb+noun (tasks) or noun+past-tense (events) conventions

Summary: Overall assessment — ✅ consistent / ⚠️ minor gaps / ❌ significant issues — with actionable next steps.

Step 7 – Write the report to a file

Determine the output file path as .claude/temp/<processName>-review.md, where <processName> is the kebab-case process name derived from the process ID (e.g. process ID newsletter-subscription → file docs/newsletter-process-review.md).

Prepend a metadata header to the report:

• **Date:** set to today's date
• **Process file:** set to the relative BPMN path
• **Process ID:** set to the process ID

Write the complete report (header and all sections from Step 6) to the output file. Confirm the file path to the user.