メニュー
Reference for releasing bpmn-to-code. Releases are automated via release-please; this skill documents the human-in-the-loop steps and edge cases.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| 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
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'.