Jeden Skill in Manus ausführen
mit einem Klick

Jeden Skill in Manus mit einem Klick ausführen

bpmn-to-code-release

Sterne8

Forks0

Aktualisiert9. Juni 2026 um 14:38

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

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

In Manus ausführen

Quelle

Miragon

Miragon/bpmn-to-code

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

In Manus ausführen

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

SoftwareentwicklerInformatik- und Mathematikberufe·SOC 15-1252

SKILL.md

readonly

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

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 touches only gradle.properties, CHANGELOG.md, and .release-please-manifest.json.
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

Mehr aus diesem Repository

gleiches Repository

create-unit-test

Miragon/bpmn-to-code

Write or refactor unit tests following the canonical project pattern. Use when adding new unit tests or standardizing existing ones.

2026-07-218

generate-rule-to-enforce-bpmn-styleguide

Miragon/bpmn-to-code

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.

2026-07-208

generate-rules-to-enforce-bpmn-styleguide

Miragon/bpmn-to-code

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.

2026-07-208

build-bpmn-styleguide

Miragon/bpmn-to-code

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

2026-07-178

create-process-service

Miragon/bpmn-to-code

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.

2026-06-178

migrate-bpmn-to-code-v1-to-v2

Miragon/bpmn-to-code

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

2026-06-178

Release – bpmn-to-code

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 touches only gradle.properties, CHANGELOG.md, and .release-please-manifest.json.

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

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)

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