Menu
Reference for releasing bpmn-to-code. Releases are automated via release-please; this skill documents the human-in-the-loop steps and edge cases.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Write or refactor unit tests following the canonical project pattern. Use when adding new unit tests or standardizing existing ones.
Generate a Kotlin SingleModelValidationRule implementation for ONE rule from BPMN_STYLE_GUIDE.md. Use when drafting / iterating on a single rule, or when the user asks to 'generate a rule for <slug>', 'create the element-id-format rule', or 'add just this one rule to the test module'. For all rules at once, use generate-rules-to-enforce-bpmn-styleguide.
Generate Kotlin SingleModelValidationRule implementations for every deterministic (or hybrid) rule in BPMN_STYLE_GUIDE.md, so they can be enforced at test time by the bpmn-to-code-testing module. llm-only rules stay in the style guide for /validate-bpmn-style. Use when the user asks to 'generate validation rules from the style guide', 'enforce BPMN conventions in CI', or 'automate style checks in tests'. For a single rule, use generate-rule-to-enforce-bpmn-styleguide.
Interactively author a BPMN_STYLE_GUIDE.md for your project — a handbook that explains how the team models BPMN processes (naming, allowed elements, IDs, topics, engine-specific special cases). The output is a document humans can read; embedded YAML annotations let downstream skills enforce the rules. Use when the user asks to 'create a BPMN style guide', 'set up BPMN conventions', or 'define BPMN naming rules'.
Create a complete Spring Boot service project from a BPMN file with hexagonal architecture. Bootstraps via Spring Initializr, configures bpmn-to-code, and generates workers, use cases, and services wired to ProcessApi constants — no raw strings anywhere. Use when the user wants to start a new process service from a BPMN model.
Migrate generated API usage from bpmn-to-code v1.1.0 to v2.0.0. Use when the user asks to 'upgrade to v2', 'migrate from v1 to v2', 'fix TaskTypes references', or 'update bpmn-to-code API calls after upgrade'.
| name | bpmn-to-code-release |
| description | Reference for releasing bpmn-to-code. Releases are automated via release-please; this skill documents the human-in-the-loop steps and edge cases. |
| allowed-tools | Bash(gh *) |
Releases are automated by release-please. There is no manual bump or tag step. The workflow .github/workflows/release-please.yml keeps a permanent "Release PR" open and publishes the GitHub Release (and its tag) immediately on merge.
main. feat: → minor, fix: → patch, feat!: / BREAKING CHANGE → major. Other types (chore, docs, refactor, build, test, …) do not bump.chore(main): release <next-version>. It touches only gradle.properties, CHANGELOG.md, and .release-please-manifest.json.v<version> created atomically) with notes generated from the commits. The release is not a draft — publishing immediately is what guarantees the tag exists, which release-please needs to anchor the next changelog.Release workflow run continues and pauses at the release approval gate. Publishing is no longer a separate workflow reacting to the published release — the publish jobs run in the same run via needs + release_created. Open the workflow run and approve the deployment (or reject to abort). This is the human gate — it replaces the old "publish the draft" step.If the commits would not produce the version you want (e.g. you need 3.0.0 without a feat!: commit), add a footer to any commit on main:
Release-As: 3.0.0
Release-please uses that version on its next run.
The Release is published automatically on merge, so notes are edited after publishing in the GitHub UI (Releases → Edit). Adjust wording, regroup items, or add a migration note — the tag and artifacts are unaffected by body edits.
gh release list --limit 5
gh workflow view "Release" --web
If the Release PR doesn't appear after a push to main, the workflow run page shows why (usually: no Conventional commits with releasable types since the last tag).
Only if automation fails. Ask the user for confirmation first. There is no single
"publish everything" workflow anymore — dispatch the individual reusable workflows
(each keeps its own workflow_dispatch + dry_run):
gh workflow run publish-to-maven.yml
gh workflow run publish-to-gradle.yml
gh workflow run publish-to-docker.yml
gh workflow run deploy-docs.yml
Verify:
gh run list --workflow=publish-to-maven.yml --limit 1