release

> **Versioning.** This skill carries a `version` (above). Bump it (patch = wording, > minor = a new step/rule, major = a changed gate) whenever you edit this file or > the policy it enforces ([`docs/VERSIONING.md`](../../../docs/VERSIONING.md)). # release — cut a Muse version the same way every time ## Overview One invocation cuts **one** release: decide the number → prove it's releasable → bump, changelog, commit, tag, push → create the GitHub Release. The single source of truth for *what a number means* is [`docs/VERSIONING.md`](../../../docs/VERSIONING.md) — this skill is its executable form. If the two ever disagree, the doc wins; fix this skill. **Two jobs must be A+ every time — follow the bundled rubric, don't improvise:** the **version decision** (patch vs minor vs major) and the **release notes** (curated from the *entire* commit history since the last tag). Both procedures, with worked examples and the quality bar, live in [`references/release-notes.md`](references/release-notes.md). Read it before Step 1 and Step 3; it is the part that makes the output identical-quality on every run. **Releases are deliberate, human-cut milestones — never automated per commit, but FREQUENT.** `main` iterates continuously (autonomous loops included), so a release is a snapshot of a chosen *known-good* commit, not a reaction to every push. Per `docs/VERSIONING.md §Release cadence` (진안, 2026-07-02): cut or propose a PATCH whenever a milestone wave completes, and never let ~30+ us...