bex: Skill for Claude Code

Task: Release a bex component

/release <component> [patch|minor|major|X.Y.Z] (Codex: $release) — cli (tag prefix bex-cli/v) or mobile (tag prefix bex-mobile/v, see the Mobile section). Sections 1–5 are written for the CLI. Reject platform until the ADR058 bex/v* train exists.

Authorization: a release request authorizes syncing shipped code, choosing the version by the rules below, pushing a new tag, running the release workflow, and verifying channels. Announce the version and source SHA, then proceed without confirmation. Honor explicit preview-only, no-publish, or exact-version constraints. A request only to edit this skill is not an instruction to publish.

Invariants (ADR058): release only code already on origin/main. Code changes land through /ship; this skill does not commit or push branches in the bex repository. Publishing the Homebrew formula remains part of the authorized release. Preserve local work. Never delete, move, or reuse an existing remote tag, even if it has no GitHub Release. Recover with a fresh version instead.

1 — Prepare the source automatically

1. Fetch origin main and tags. On clean main that is behind, fast-forward with git merge --ff-only origin/main; do not stop to ask. If the checkout is dirty, on another branch, ahead, or diverged, use a temporary detached worktree at origin/main. Do not stash, reset, rebase, include local commits, or disturb another session's work. Keep temporary verification artifacts outside the user's checkout.
2. Record the fetched main SHA as the release candidate. Inspect its full commit message before tagging for GitHub skip instructions: [skip ci], [ci skip], [no ci], [skip actions], [actions skip], or skip-checks: true. These also suppress tag-push workflows; a successful CodeQL run alone does not establish release readiness.
3. If the tip has a skip instruction, inspect the intervening commits and diff to the nearest first-parent ancestor without one. Automatically select that ancestor only if every intervening change is a generated deployment image-reference pin, with no source, dependency, build, installer, or workflow changes. Verify the diff itself, not just commit subjects. Record this source choice and keep the checkout at main (or use a detached worktree); tag the selected SHA explicitly. For any broader difference, prepare the necessary fix and stop at the /ship boundary rather than silently omitting shipped code.
4. Determine required checks from repository rules and the component's workflows. Inspect individual jobs on the selected SHA, including reusable test jobs inside deploy.yml. All required checks and relevant tests must pass; wait for pending checks and retry genuine infrastructure flakes at most twice. For CLI, cover launcher/pin validation, installer checks, and backend device-flow/API tests as specified by the current workflows. Run missing applicable checks from the selected source locally where supported. No runs, skipped checks, or a docs-only green run are not proof that tests passed.
5. Platform image builds, Helm mirroring, and cluster rollouts are not CLI release gates unless repository rules explicitly require them. Once the required checks and relevant test jobs pass, proceed without waiting for unrelated deployment steps. Do not ignore a required failure. For real code defects, diagnose and prepare a fix; land it through /ship only when separately authorized.
6. Re-fetch main before publication. If it advanced with release-relevant changes, update the candidate and repeat the applicable checks. If only unrelated changes or generated pins advanced, keep the validated candidate after verifying it is still an ancestor of origin/main and release inputs are unchanged. Do not chase deployment write-back commits indefinitely.