Automates the Pipelex API release workflow: bumps the version in pyproject.toml, finalizes the CHANGELOG.md Unreleased section, runs quality checks, creates a release/vX.Y.Z branch, commits, pushes, and opens a PR to main. Use when user says "release", "cut a release", "bump version", "prepare a release", "make a release", "ship it", "create release branch", or any variation of shipping a new version of pipelex-api. The user can optionally provide changelog content inline when invoking the skill (e.g. "/release Added new auth backend"), which will be used as the changelog entry for this version.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
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.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Automates the Pipelex API release workflow: bumps the version in pyproject.toml, finalizes the CHANGELOG.md Unreleased section, runs quality checks, creates a release/vX.Y.Z branch, commits, pushes, and opens a PR to main. Use when user says "release", "cut a release", "bump version", "prepare a release", "make a release", "ship it", "create release branch", or any variation of shipping a new version of pipelex-api. The user can optionally provide changelog content inline when invoking the skill (e.g. "/release Added new auth backend"), which will be used as the changelog entry for this version.
Pipelex API Release Workflow
This skill handles the full release cycle for the pipelex-api Python package.
uv.lock — regenerated via make li (lock + install)
docs/openapi/pipelex-api.openapi.yaml — regenerated via make openapi-export. The artifact embeds the app version in info.version, so bumping pyproject.tomlalways makes it stale. This must be regenerated after the bump or CI's make openapi-check fails.
Workflow
1. Pre-flight checks
Read the current version from pyproject.toml.
Read CHANGELOG.md to understand the current state.
Run git status and git log origin/main..HEAD to assess the working tree:
If there are uncommitted changes (staged or unstaged), warn the user and
ask whether to commit them as part of the release, stash them, or abort.
If there are unpushed commits on the current branch, list them so the
user is aware — these will be included in the release branch.
2. Determine the bump type
Ask the user which kind of version bump they want — patch, minor, or
major — unless they already specified it. Show the current version and what
the new version would be for each option so the choice is concrete.
3. Run quality checks (pre-bump gate)
Run make check. This is the entry gate — if it fails, stop and report the
errors so they can be fixed before retrying. Do not proceed past this step on
failure.
This runs before the version bump, so it validates the current version, not
the release version. In particular it does NOT catch the OpenAPI artifact
going stale from the bump itself — docs/openapi/pipelex-api.openapi.yaml
embeds info.version, so the bump always invalidates it. That is what the
post-bump regeneration + re-check in step 7.5 exists to catch. Do not rely
on this step alone. (Note: make agent-check / make c / make cc skip
openapi-check entirely — only full make check and CI run the drift gate, so
always use make check here, never a lighter variant.)
4. Ensure we're on the right branch
The release branch must be named release/vX.Y.Z where X.Y.Z is the new
version. All file modifications (changelog, version bump, lock) must happen on
this branch.
If already on release/vX.Y.Z matching the new version, stay on it.
If on dev, main, or any other branch, create and switch to
release/vX.Y.Z from the current HEAD.
If on a release/ branch for a different version, warn the user and ask
how to proceed.
5. Finalize the changelog
Add a new version entry at the top of the changelog for the release.
If there is an ## [Unreleased] section, remove it (including any blank
lines that follow it) and replace it with the new version heading. Any
content that was under [Unreleased] becomes the content of the new version.
If there is no [Unreleased] section, insert the new version heading
directly after the # Changelog title.
Never add an [Unreleased] heading. The changelog should only contain
concrete version entries.
If the user provided changelog content when invoking the skill (e.g.
/release Added new auth backend), merge that content with any
existing [Unreleased] content (do not discard either source). Format the
combined content properly under the appropriate headings (e.g. ### Added,
### Changed, ### Fixed), inferring headings from the content when
possible.
If the release has no changelog content yet (neither from an [Unreleased]
section nor from inline user input), ask the user what to include before
proceeding.
Edit pyproject.toml line 3 to the new version string. Only change the version
field — don't touch anything else.
7. Lock dependencies
Run make li to regenerate uv.lock and reinstall. This ensures the lockfile
reflects the new version in pyproject.toml. If this step fails, stop and
report the error.
7.5. Regenerate the OpenAPI artifact and re-run the full check
The version bump in step 6 makes the committed OpenAPI artifact stale (its
info.version still reads the old version). Regenerate and re-validate against
the final release state — this is the step that the pre-bump gate (step 3)
structurally cannot cover:
Run make openapi-export to regenerate docs/openapi/pipelex-api.openapi.yaml
from the bumped app. Confirm the diff is the expected info.version change
(and any genuine schema changes from the release); anything unexpected means
the artifact had already drifted and should be investigated.
Run make check again as the final gate on the committed state. It must pass
— openapi-check here is exactly what CI runs, so a green make check now
means CI's OpenAPI drift gate will pass. If it fails, stop and fix before
committing.
Do not skip this even if step 3 was green: step 3 ran before the bump and cannot
see version-driven drift.
8. Commit and push
Stage all release-related changes. This includes at minimum pyproject.toml,
CHANGELOG.md, uv.lock, and docs/openapi/pipelex-api.openapi.yaml, plus any
other files the user chose to include in step 1 (e.g. previously uncommitted
work that belongs in this release).
Commit with the message:
Release vX.Y.Z
Push the branch to origin with -u to set up tracking.
9. Open a PR
Create a pull request targeting main with:
Title:Release vX.Y.Z
Body: Include:
The changelog entries for this version (copied from CHANGELOG.md)
A note about the version bump from old to new
Use this format for the PR body:
## Release vX.Y.Z
Bumps version from `A.B.C` to `X.Y.Z`.
### Changelog<pastethechangelogentriesforthisversionhere>
Report the PR URL back to the user.
Important details
The version follows semver: MAJOR.MINOR.PATCH.
Always confirm the bump type with the user before making changes.
If make check fails, the release is blocked — help the user fix the issues
rather than skipping the checks.
The OpenAPI artifact tracks the version.docs/openapi/pipelex-api.openapi.yaml
embeds info.version, so every bump makes it stale and CI's make openapi-check
will fail unless it is regenerated (step 7.5) and committed. The pre-bump
make check (step 3) cannot catch this because it runs before the bump.
Today's date for the changelog entry: use the current date in YYYY-MM-DD
format.
