Miragon AIImplement
bpmn-to-codeA rename in the model breaks the build, not the running process.
A Gradle and Maven plugin that turns the element ids, topics, job types and messages of your BPMN models into Kotlin or Java constants, for Camunda 7, CIB seven, Operaton and Camunda 8.
grep -n ORDER_BIKE src/main/kotlin/OrderBikeWorker.kt9:@ExternalTaskSubscription(ServiceTasks.MIRAVELO_ORDER_BIKE)./gradlew build> Task :generateBpmnModelApi Generated: bikeLeasing (from bike-leasing.bpmn)> Task :compileKotlinBUILD SUCCESSFUL in 972ms# in the model, the topic becomes miravelo.placeBikeOrder./gradlew build> Task :compileKotlin FAILEDe: file:///private/tmp/miravelo/src/main/kotlin/OrderBikeWorker.kt:9:40 Unresolved reference 'MIRAVELO_ORDER_BIKE'.BUILD FAILED in 902msThe problem
Nothing tells your code when the model changes
Workers, message correlation and process tests carry names from the model as strings: topics, job types, message names, element ids. When someone renames one in the modeler, the code still compiles. You find out at runtime, when a worker stops picking up its tasks or a message finds no instance.
Today
- Workers carry their topic or job type as a string copied from the modeler
- A topic renamed in the model still compiles, and the instance waits for a worker that never comes
- Process tests type element ids by hand and fail only when they run
- A service task without a topic shows up when the engine rejects the deployment
With bpmn-to-code
- Workers reference a generated constant for each topic and job type
- The next build after the rename names every worker that still uses the old constant
- A ProcessPath built from the generated flow nodes stops compiling when the model no longer has that path
- Generation stops on a service task without implementation, a message without a name or a timer without a definition
How it works
From the model to constants, on every build
One task reads a set of BPMN files for one engine, one language and one package. A project that mixes engines registers one task per group.
Add the plugin
Apply the Gradle plugin or bind the Maven goal, and set the engine, the output language and the package.
Generate
generateBpmnModelApi checks every model against the built-in rules, then writes one ProcessApi object per BPMN file and shared objects such as ServiceTasks, Messages and Errors.
Reference
Workers, process adapters and process tests use the constants and the typed FlowNodes instead of strings.
Rebuild
After a change to the model, the next build regenerates the API, and the compiler points at every line that no longer fits.
What you get
Generated code your compiler checks
The plugin writes ordinary source files into the folder you choose. Generate into the build directory to keep them out of Git, or commit them and let CI check that they are current.
Validation before generation
Built-in rules stop the run on an error and write nothing. The testing library bpmn-to-code-testing adds rules of your own, such as your modelling conventions.
Process paths that compile
ProcessPath walks a route through the generated flow nodes and hands its ids to the flow assertion of your test library.
No engine dependency
The generated code is plain constants and objects. Kotlin and Java need only bpmn-to-code-runtime, which the Gradle plugin adds for you.
Same model, same code
The output depends only on the BPMN files and the configuration, so a CI job can regenerate and fail when committed code is out of date.
Kotlin, Java or C#
Kotlin and Java use the small runtime library. C# output is experimental and carries its types in each file.
Without a build
The web app takes up to three BPMN files in the browser, and the Docker image miragon/bpmn-to-code-web runs it on your own infrastructure.
For your coding agent
Your agent writes against the generated API
A Claude Code plugin with eight skills and one subagent, in beta. Each skill does one thing for one element, in Kotlin or Java: on Camunda 8, on Camunda 7, CIB seven or Operaton with delegates or external tasks, or through the process-engine-api.
- SetupPlugin and migrationsetup-bpmn-to-code detects build tool, engine, language and BPMN files and configures the plugin. migrate-to-bpmn-to-code-apis replaces hardcoded strings with the generated constants.
- Engine codeOne element at a timecreate-worker writes the handler for one service task and create-process-adapter one call to the engine, each with a test skill. test-process runs a scenario and asserts its ProcessPath.
- Style guideYour rules as testsgenerate-rule-to-enforce-bpmn-styleguide turns one rule of your BPMN_STYLE_GUIDE.md into a validation rule for the testing library.
- Reviewprocess-reviewerA subagent that checks one process against its code, from one handler per job type to a process test per branch. It reports and changes nothing.
Status
Where bpmn-to-code stands on 18 October 2026
bpmn-to-code is at 6.5.0, released on 18 October 2026 to the Gradle Plugin Portal and Maven Central. The repository is public under the MIT licence. Major versions bring breaking changes, and the docs have a migration guide for each.
Agent Skills in beta
Skill names and instructions may still change.
Newer parts are experimental
The command-line tool (new in 6.5.0), the validate task and C# output may change in a minor release.
Process JSON is deprecated
The compact JSON view of each process goes away in 7.0.
Declared variables only
A variable that only occurs inside an expression, such as a gateway condition, gets no constant. The model is the contract for its variables.
Build time only
bpmn-to-code neither deploys nor runs a model. On your dev engine, the Skills and operate do that.
The business logic is yours
The skills write a handler and its test. The use case the handler calls stays your team's code.
Proof you can open
Everything here is public
- Miragon/bpmn-to-codeThe source under the MIT licence, with the README and the changelog.Open
- Gradle Plugin PortalThe plugin io.miragon.bpmn-to-code-gradle, version 6.5.0.Open
- Maven CentralThe Maven plugin io.miragon:bpmn-to-code-maven and the runtime library, version 6.5.0.Open
- Web appGenerate from your own BPMN files in the browser, without an install.Open
- Drift in a workerA clip of a topic string that drifts from the model, and of the build that points at the worker once it uses the constant.Open
- Blueprint on CIB sevenA bike-leasing service whose external-task workers and tests use the generated API, in Kotlin with Gradle and in Java with Maven.Open
Where it fits
bpmn-to-code in the lifecycle
bpmn-to-code reads the models your team released in Design and made deployable in Implement. What it generates lives in your codebase and runs with your workers in Execute.
- PhaseImplementWhere your team makes the model run. bpmn-to-code ties the code around it to the model.Learn more
- Same phaseSkillsThe bpmn skill sets topics and job types by element id, and bpmn-to-code turns them into constants.Learn more
- Reads models withbpmn-cliThe Agent Skills read models through bpmn-cli, and the bpmn-to-code plugin installs the bpmn-cli plugin with it.Learn more
- From DesigndesignIQYour team models in designIQ and releases by pull request. The merged .bpmn file is what bpmn-to-code reads.Learn more
- Deploy and testoperateDeploys the model to Camunda 7, CIB seven or Operaton and runs a test instance.Learn more
- Next phaseExecuteYour workers run against the engine, and Pulse and operate show what is stuck.Learn more
Docs
The full reference is in the docs
- Generated APIWhat the generated files contain and how to use them.Open
- Process pathsTyped routes through the model for your process tests.Open
- ValidationThe built-in rules, the validate task and the testing library.Open
- All docsConfiguration, engines, the web app and the changelog with its migration guides.Open
Tie your process code to your models.
Tell us which engines and build tools you use and how your workers find their topics today. Together we check where bpmn-to-code and its skills fit into your codebase.
Talk to usA 30-minute first call.