releaselisted

# Release VibeTags Drives the release process documented in `docs/RELEASING.md`. That document is the source of truth; this skill is the executable path through it. If the two ever disagree, `docs/RELEASING.md` wins — and say so rather than silently improvising. ## Step 1 — Establish the current version and ask for the next one The single source of truth for "what version are we on" is the `<vibetags.version>` property in `vibetags-bom/pom.xml`: ```bash sed -n 's:.*<vibetags\.version>\(.*\)</vibetags\.version>.*:\1:p' vibetags-bom/pom.xml | head -n1 git tag --sort=-v:refname | head -5 ``` Then **ask the user which version to release** with `AskUserQuestion`. Compute the candidates from whatever the current version turns out to be — do not hardcode them: - If the current version is a release candidate (`X.Y.Z-RCn`), offer promoting it to final (`X.Y.Z`) and cutting the next candidate (`X.Y.Z-RC<n+1>`). - If the current version is final, offer the patch, minor, and major bumps, and a first release candidate for the next minor if that fits what is in `[Unreleased]`. Always include the semantic-versioning meaning in each option's description. The user can also type any version via "Other". Never guess and proceed — the version is always the user's call. Sanity-check the answer before continuing: it must be a release version (no `-SNAPSHOT` — Maven Central rejects those), and `git tag -l "v<version>"` must come back empty. ## Step 2 — Preflight Refuse to continue and