source-command-release

name	source-command-release
description	Review and merge the release-plz release PR with explicit user confirmation

source-command-release

Use this skill when the user asks to run the migrated source command release.

Command Template

Release

Releases are driven by release-plz (release-plz.toml + .github/workflows/release-plz.yml). On every push to main it maintains a chore: release vX.Y.Z PR with the version bump and CHANGELOG update derived from conventional commits. Merging that PR ships the release — release-plz pushes the vX.Y.Z tag, which triggers release.yml (static binaries, GitHub release, crates.io, Docker) and flakehub-publish-tagged.yml.

This command walks that flow safely. Never merge the release PR without explicit user confirmation — it is an outward-facing, hard-to-reverse action.

Phase 1: Locate the release PR

gh pr list --repo utensils/nxv --search "chore: release in:title" --state open

If none exists, check whether main has unreleased conventional commits since the last tag (git log $(git describe --tags --abbrev=0)..origin/main --oneline). If there are releasable commits but no PR, check the latest Release-plz workflow run for errors (gh run list --workflow release-plz.yml).

Phase 2: Review what will ship

1. Show the PR's version bump (Cargo.toml diff) and CHANGELOG addition.
2. Verify the version follows the project convention: feat: commits bump the 0.x minor (features_always_increment_minor = true), fixes bump patch.
3. If the version or changelog is wrong, edit the release PR directly (it is a normal editable PR) — release-plz preserves manual edits unless new commits land on main.

Phase 3: Pre-flight

1. All CI checks on the release PR must be green. If checks show "Expected / Waiting", the App token is misconfigured — see release-plz.yml comments.
2. Confirm no other PR is about to land that should be in this release.

Phase 4: Confirm and merge

Present a summary (version, commit list, changelog) and require the user to confirm with the explicit version number (AskUserQuestion). Then:

gh pr merge <PR> --repo utensils/nxv --squash

Phase 5: Monitor

1. The Release-plz workflow on main pushes the tag.
2. The Release workflow builds binaries and publishes — monitor with gh run list --workflow release.yml / gh run watch.
3. Verify the GitHub release has all four binaries + SHA256SUMS.txt, crates.io has the new version, and ghcr.io has the version tag.

Manual escape hatches

• Tagging failed after the release PR merged: re-run the Release-plz workflow on main (it is idempotent — existing tags are the gate).
• The old fully-manual flow (bump Cargo.toml, edit CHANGELOG, tag by hand) still works in emergencies but must match release-plz's expectations (tag vX.Y.Z, CHANGELOG section ## [X.Y.Z] - YYYY-MM-DD).