← ClaudeAtlas

release-taglisted

Cut a release by determining the SemVer bump from history, updating version files across any stack, refreshing the changelog, creating an annotated (optionally signed) Git tag, and pushing the release safely after pre-flight checks. Use when tagging a version, bumping the version, or preparing a release.
KhaledSaeed18/dotclaude · ★ 0 · AI & Automation · score 75
Install: claude install-skill KhaledSaeed18/dotclaude
Take the repo from "ready" to a clean, tagged, pushed release. Releases are outward-facing and effectively irreversible once published, so every step is gated by pre-flight checks and explicit confirmation. ## Hard rules: never break these - **Never release a dirty or unverified tree.** Working tree clean, on the correct branch, up to date with the remote, and tests/CI green; all true before tagging. - **Tags are immutable once published.** Never move or overwrite a pushed tag; if a release is wrong, cut a new patch version. Force-retagging breaks everyone who already pulled. - **Follow SemVer honestly.** The bump must reflect what actually changed (see Step 2), not a convenient number. - **Confirm before the commit, the tag, and the push.** These are the irreversible, outward-facing actions. - **No AI/co-author trailers** in the release commit or tag message. - **Publishing is downstream.** Tagging ≠ publishing to a registry. Don't run `npm publish` / `cargo publish` / etc. unless explicitly asked; most pipelines publish from CI on tag. ## Step 1: Pre-flight - `git status` → clean tree (or stash/commit deliberate changes first). - On the release branch (usually `main`/`master` or a `release/*` branch) and synced: `git fetch && git status` shows up to date. - Latest tag and history since it: `git describe --tags --abbrev=0`. - Tests, linters, and build pass locally; CI on the release commit is green. ## Step 2: Determine the version Derive the SemVer bump from the commi