Bpmn to code release

Skill Miragon/bpmn-to-code/.claude/skills/bpmn-to-code-release

Reference for releasing bpmn-to-code. Releases are automated via release-please; this skill documents the human-in-the-loop steps and edge cases.From its SKILL.md

Install

npx -y skills add Miragon/bpmn-to-code --skill bpmn-to-code-release

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

13 stars13 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.3 KB, as published. Nobody here has run it

Release – bpmn-to-code

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.

Normal flow

Conventional commits land on main. feat: → minor, fix: → patch, feat!: / BREAKING CHANGE → major. Other types (chore, docs, refactor, build, test, …) do not bump.
Release-please opens / updates a PR titled chore(main): release <next-version>. It bumps gradle.properties, CHANGELOG.md, .release-please-manifest.json, and — via the extra-files list in release-please-config.json — the version in every install snippet in the READMEs and docs/ (each wrapped in invisible  /  HTML-comment markers). Version-specific migration guides and ADRs are intentionally not registered and stay untouched.
Merge the Release PR when you want to ship.
A published GitHub Release is created (tag 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.
The same 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.
After approval, the publish jobs run: Maven Central → Gradle Plugin Portal, Docker Hub, and the GitHub Pages docs deploy.

Force a specific bump (edge case)

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.

Edit release notes

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.

Sanity checks

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).

Manual publishing (fallback)

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