Cut Release

Drive a release from "the code is ready" to "the artifacts are published", with evidence at every step. Releases fail late and expensively — a version mismatch discovered by the publish workflow wastes a tag and a CI run — so this skill front-loads every check that can fail before anything irreversible happens.

0. Learn this repo's release contract first

Read, in order of authority: the repo's release doc (docs/release.md, RELEASE.md, or a ## Release section in README/CONTRIBUTING), the release workflow under .github/workflows/ (what triggers it — usually a v* tag — and what it publishes), and the previous release tag (git tag --sort=-creatordate | head) for naming conventions. The repo's documented process always overrides the generic steps below; this skill fills gaps, it does not replace a written contract.

1. Pre-flight — everything that can fail cheaply

Run all of these before touching a version number; stop on the first failure:

• Clean state: working tree clean, on the default branch, up to date with origin.
• Version-sync inventory: find every file that carries the version (Cargo.toml, package.json and per-platform npm/platforms/*/package.json with their optionalDependencies, pyproject.toml, a version.go constant, docs). If the repo ships a checker (e.g. a check-versions script), it is the authority — run it. If not, grep the current version and list every hit; that list is the bump checklist.
• Verification gate: the repo's full verify pipeline (make verify or equivalents). Any warning is a blocker — release CI usually runs the same gate and fails late.
• Changelog/release notes: if the repo maintains one, confirm the new version's entry exists (generate from Conventional Commits history when that is the convention).

2. Bump and prove