release

name	release
description	Cut and ship a Soloist release. Reads what merged since the last release, decides the semantic-version bump, syncs the version across the three manifests, tags, and pushes so CI builds and publishes the GitHub Release the in-app updater reads from. Use when the user wants to release, ship, publish, or bump the app version.
argument-hint	[patch|minor|major|X.Y.Z]
disable-model-invocation	true
allowed-tools	Bash(git *), Bash(gh *), Bash(bash *), Read

Cut a release

You are cutting a real release. Pushing the tag makes CI build the signed .deb and .AppImage and publish a GitHub Release that every installed copy of Soloist will auto-update to. So the version has to be right and the tree has to be clean. Decide the version from the evidence in front of you, and don't guess.

${CLAUDE_SKILL_DIR}/scripts/release.sh does the mechanical part: it writes the version into the three manifests, commits, tags, and pushes, and it refuses to run on a dirty or diverged tree. What it can't do is choose the number. That part is yours, and it's the whole reason this isn't a one-line script.

1. Read the state

Run these and read the output before deciding anything:

git fetch --quiet origin main --tags
cur=$(sed -n 's/.*"version": "\([0-9][0-9.]*\)".*/\1/p' crates/app/tauri.conf.json | head -1)
echo "current version: $cur"
git log --oneline "v$cur"..HEAD
git diff --stat "v$cur"..HEAD | tail -1

Also pull the merged PRs since the last release for their titles and labels:

since=$(git log -1 --format=%cs "v$cur")
gh pr list --state merged --base main --search "merged:>=$since" \
  --json number,title,labels --jq '.[] | "#\(.number) \(.title) [\(.labels|map(.name)|join(","))]"'

If nothing has merged since v$cur, stop and say so. There is nothing to release.

2. Decide the version

If the user passed an argument, honor it:

• patch, minor, or major: bump that part of $cur.
• A literal X.Y.Z: use it as-is, as long as it is higher than $cur.

$ARGUMENTS

With no argument, decide from what you just read. Soloist is pre-1.0, and pre-1.0 semver works a little differently: the leading 0. stays put, so even a breaking change bumps the minor rather than the major. The commits follow Conventional Commits, so read them as your main signal:

• Minor (0.2.0 → 0.3.0) when the range adds a feature or changes behavior in a backward-incompatible way: any feat(...), or a ! / BREAKING CHANGE.
• Patch (0.2.0 → 0.2.1) when the range is only fixes, refactors, docs, tests, deps, or tooling: fix, perf, refactor, docs, test, build, chore, ci.
• Take the highest bump any single change in the range calls for. One feat among ten fixes is still a minor.
• Major (→ 1.0.0) is a deliberate call to leave 0.x. Never reach for it on your own. Cut it only when the user explicitly asks to go 1.0.

Diff size only breaks ties. A one-line feat is still a minor, and a thousand-line refactor is still a patch. When the commits genuinely don't settle it, pick patch and say why.

Before you act, state the version you chose and the change or two that drove it.

3. Cut it

bash "${CLAUDE_SKILL_DIR}/scripts/release.sh" <version>

The script validates the version, checks that you are on a clean and current main, confirms the tag is free, writes the version into Cargo.toml, crates/app/ui/package.json, and crates/app/tauri.conf.json, then commits, tags vX.Y.Z, and pushes. If it exits non-zero, read the message and fix what it flags. Don't work around it.

4. Confirm

The script prints the build and release URLs. Report them, and watch the run if you want to see it through:

gh run watch --exit-status "$(gh run list --workflow=release.yml --limit 1 --json databaseId --jq '.[0].databaseId')"

Once the run is green, the release is public and the in-app updater will offer it. If the run fails, remember that the tag is already pushed, so fix forward with the next patch instead of deleting a published tag.