release

name	release
description	Cut a bnot release — compute next version, push main, and create a GitHub release that triggers the build/sign/notarize workflow.
disable-model-invocation	true
argument-hint	[patch|minor|major|x.y.z] # omit for patch bump
allowed-tools	Bash(gh:*), Bash(git:*)

Cut a new bnot release. The user invoked /release $ARGUMENTS.

How bnot releases work

The release is triggered by creating a GitHub Release (gh release create) with a semver tag. The release.yml workflow fires on release: created, reads the version from the tag, writes it into apps/desktop/tauri.conf.json and apps/desktop/Cargo.toml inside the runner only (not committed back), then builds, signs, notarizes, and uploads the universal .app + DMG + updater artifacts.

Never bump version strings in the repo. The workflow owns them.

Steps

1. Pre-flight checks (fail fast)

Run these in parallel, then report any failures and stop:

• git rev-parse --abbrev-ref HEAD — must be main. If not, stop and ask.
• git status --porcelain — must be empty (no dirty working tree). If dirty, stop and tell the user to commit or stash first. Do NOT auto-commit.
• git log origin/main..HEAD --oneline — capture the unpushed commits; they're the release payload.
• gh auth status — must be authenticated. If not, stop.

2. Compute the next version

Get the latest release tag:

gh release list --limit 1 --json tagName,isDraft,isPrerelease

Strip the leading v to get the base version (e.g., v0.1.16 → 0.1.16). Then apply $ARGUMENTS:

• empty / patch → bump patch (0.1.16 → 0.1.17)
• minor → bump minor, reset patch (0.1.16 → 0.2.0)
• major → bump major, reset minor+patch (0.1.16 → 1.0.0)
• x.y.z (exact semver) → use as-is

Validate the final version against ^[0-9]+\.[0-9]+\.[0-9]+$ — the workflow rejects non-semver tags. If $ARGUMENTS is none of the above, stop and ask.

Check the tag doesn't already exist on remote:

git ls-remote --tags origin "refs/tags/v$VERSION"

If it returns anything, stop — the tag already exists.

3. Confirm with the user

State in one line: "Cutting vX.Y.Z from main at <short-sha> with N commits since vPREVIOUS." Show the commit subjects (one line each). Then ask for confirmation before pushing. In auto mode, proceed if there are no red flags; otherwise still ask.

4. Push main

git push origin main

Must succeed before creating the release, or the workflow would check out code without the commits being released.

5. Create the release (this triggers the workflow)

gh release create "v$VERSION" --title "v$VERSION" --generate-notes --target main

--generate-notes fills the body from PRs/commits since the previous tag. --target main pins the tag to the pushed HEAD.

6. Report back

Print the release URL from gh release view "v$VERSION" --json url -q .url and mention that the workflow is running — direct the user to gh run list --workflow=release.yml --limit=1 or the Actions tab to watch it. Do NOT poll the workflow unless the user asks.

Guardrails

• Do NOT edit version fields in apps/desktop/tauri.conf.json, packages/sidecar/package.json, apps/desktop/Cargo.toml, or packages/bridge/Cargo.toml. The workflow handles it.
• Do NOT git tag locally — gh release create creates the tag on the remote as part of the release.
• Do NOT --force push or reuse an existing tag.
• If any step fails, stop and surface the error — don't try to "fix forward" into a half-released state.