원클릭으로 Manus에서 모든 스킬 실행

bpmn-to-code-release

스타8

포크0

업데이트2026년 6월 9일 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.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

Miragon

Miragon/bpmn-to-code

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

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

이 저장소의 다른 Skills

같은 저장소

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

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

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