Version Release

Version Release

Trigger patterns

Start this skill when the user says any of:

• "升级版本到 x.x.x" / "bump version to x.x.x"
• "发布版本 x.x.x" / "release version x.x.x"
• "重新发布版本 x.x.x" / "regenerate release x.x.x"
• "升级 patch/minor/major 版本"
• "release" combined with a version number or bump type

🚨 HARD RULE — the tag points at the release commit and nothing else

The version tag vx.x.x may ONLY ever be bound to the release commit 🔖 chore[release]: bump version to x.x.x. Never bind it to any other commit — not a fix, not a chore, not a merge. The tag is what triggers the GitHub Actions release build, so a tag on a non-release commit ships an unversioned, unverified tree and can publish broken artifacts.

Every release, every re-tag, every regenerate — this rule is non-negotiable:

1. The release script creates the tag at HEAD right after the release commit, and its hard-rule guard refuses to tag if HEAD's subject is not exactly 🔖 chore[release]: bump version to x.x.x.
2. When reordering, rebase-rebuilding, or manually moving a tag: rewrite the history first so the release commit is the tip, then tag that commit.
3. Before pushing, verify the binding: git rev-parse <tag>^{} must resolve to a commit whose subject is 🔖 chore[release]: bump version to x.x.x (git log -1 --pretty=%s <tag>^{}).
4. Push the branch first, the tag last.

Release workflow (single script, two passes for RELEASE.md)

Pre-release Check Gate

Before any version bump or release (including --regenerate), apply the release gate to the final tree, and commit any formatting-only changes as a separate, prior 🎨 style commit.

The release flow does not build anything locally — building is performed remotely by the GitHub Actions release.yml workflow when the v* tag is pushed. The local gate therefore runs format + check + lint (no build):

1. npm run format:check — prettier (format:prettier:check) + rustfmt (format:rust:check)
2. npm run check — svelte-check type checking
3. npm run lint:rust — cargo clippy -D warnings

⚠️ The extreme-release build (fat LTO, opt-level 3, codegen-units 1) is GitHub Actions-only and must NEVER be run locally. It is enabled solely by the environment variables CARGO_PROFILE_RELEASE_LTO, CARGO_PROFILE_RELEASE_OPT_LEVEL, and CARGO_PROFILE_RELEASE_CODEGEN_UNITS set in .github/workflows/release.yml when the v* tag is pushed. The local [profile.release] in src-tauri/Cargo.toml is intentionally fast and unoptimized (opt-level 0, codegen-units 256) — do not override it locally, and never run the extreme build by hand.

If any diffs appear, apply them (npm run format:prettier / npm run format:rust), then re-run the gate. Commit all formatting-only changes in a single 🎨 style[...]: apply formatting commit before the release commit.

The release script bumps the version first (Pass 1), so run the gate on the code before starting, then re-check RELEASE.md after curating it (see Pass 2 note below).

Prerequisite: only version files in the release commit

Before running the release script, ensure that every other change has already been committed separately.

The release commit (🔖 chore[release]: bump version to x.x.x) must only contain:

• package.json
• src-tauri/tauri.conf.json
• src-tauri/Cargo.toml
• src-tauri/Cargo.lock
• CHANGELOG.md
• RELEASE.md

Any change to scripts, skills, references, tests, or other source files must be committed before the release. The release script's git diff --name-only may pick up unrelated dirty files — verify the staged diff before allowing the commit.

Run:

node skills/version-release/scripts/release.mjs <version>

The script does the following:

The script is idempotent: re-running with the same version skips already-done steps, and changelog.mjs replaces this version's existing ## <version> ( section instead of prepending a second copy of it, so running both passes leaves exactly one section. It also accepts both [scope] and (scope) commit subjects and warns on a subject or type it cannot map, rather than dropping the commit silently.

Pass 1 — Script bumps + generates changelog

node skills/version-release/scripts/release.mjs <version>

Steps 1–2 run, then Step 3 detects stale RELEASE.md and exits.

Between passes — LLM generates RELEASE.md

Read CHANGELOG.md and use skills/version-release/release_template.md as a format reference:

1. Group related commits into feature areas
2. Attach commit hash links:

   - **Feature description** — detail | [`hash`](https://github.com/muutot/Clipboard/commit/hash)

3. Write the curated body to RELEASE.md

Do NOT commit — Pass 2 will include RELEASE.md in the release commit automatically.

Pass 2 — Script commits + tags + pushes

Re-run the same command — already-bumped steps skip, RELEASE.md check passes:

node skills/version-release/scripts/release.mjs <version>

Steps 3–6 run: check, commit, tag. Remote push is the user's manual step (the script never pushes).

Re-check formatting after curation. RELEASE.md is written after the pre-release gate. Before Pass 2, run npm run format:prettier:check (or npm run format:prettier -- RELEASE.md to fix) so the freshly curated RELEASE.md is prettier-clean. Fix any diff (npx prettier --write RELEASE.md), then commit it either as a separate 🎨 style[release] commit or folded into the release commit — do not push a release whose RELEASE.md fails the format gate.

Semantic bump

node skills/version-release/scripts/release.mjs patch    # 0.1.0 → 0.1.1
node skills/version-release/scripts/release.mjs minor    # 0.1.0 → 0.2.0
node skills/version-release/scripts/release.mjs major    # 0.1.0 → 1.0.0

Same two-pass flow applies.