release-automationlisted

Enforce and automate releases in CI so a promotion to the production branch can never silently ship without a version bump. The enforced/automated sibling of the invoked `release` skill. Use when the user asks to "enforce version bumps", "block merge without a release", "auto release on merge", "auto-release dependency updates", or "stop forgetting to tag releases".
agigante80/forge-kit · ★ 0 · AI & Automation · score 60

Install: claude install-skill agigante80/forge-kit

# Release automation Make the missing release impossible. The `release` skill is the *invoked* ship someone runs; this is the *unattended* CI layer that runs without being invoked, so a merge to the production branch with no version bump is **blocked** (or, where appropriate, auto-bumped), never silently shipped. It is a generic template: `forge-adapt` tailors the production branch, the version source, and the CI provider. > **Composition, not duplication.** Semver rules and the version source live in > `docs/versioning.md` and the `release` skill. This skill *enforces* them, it does not restate > them. See `references/semver-operator-contract.md` and `references/source-of-truth.md`. ## The one mechanism: version vs latest tag All lanes share a single primitive (`assets/version-lib.sh`) that compares the working-tree version against the latest **released tag** (not the previous commit; the tag is the only truth for "what is released") and prints one verdict: | Verdict | Meaning | What a lane does with it | |---|---|---| | `first-release` | no release tag yet | allow | | `ahead` | version > latest tag, already bumped deliberately | **ship as-is, never re-bump** | | `equal` | version == latest tag, nobody bumped | the lane's policy decides (block, or auto-patch) | | `behind` | version < latest tag, branch is stale | **hard stop (regression)** | The `ahead`/`behind` handling is the load-bearing part: it is what stops a naive "always