How do I install the Release skill?

Run npx skillmds@latest add rokartur/release in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Release safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Release?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Release free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Release?

rokartur (@rokartur) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Release by rokartur — Agent Skill

Name: Release
Author: rokartur

File contents

Release runbook

One command does the heavy lifting; this skill is the order of operations and the failure points around it.

1. Preflight

Working tree clean on main, and the unit suite green:

xcodebuild -scheme "BetterCmdTab Debug" -destination 'platform=macOS' test

scripts/set_version.sh --show prints the current version. MAJOR tracks the macOS year; tags are bare (26.4.3, 26.0-beta.1 — no v prefix on new tags).

2. Bump the version (stable releases)

scripts/set_version.sh <version>   # sets MARKETING_VERSION and auto-commits "chore: bump …"

Skip for betas — build_release.sh --beta derives the next beta.N from existing GitHub tags itself.

3. Write the notes

Produce the release body with the release-changelog skill and save it to a file (e.g. notes.md in the scratchpad). The body is the GitHub Release description; its headings are parsed by build_release.sh, so the canonical structure from that skill is mandatory.

4. Build, sign, notarize, publish

--notes takes the notes text, not a path — pass the file through cat or the literal filename becomes the release body:

scripts/build_release.sh --auto-release --notes "$(cat notes.md)"          # stable
scripts/build_release.sh --beta --auto-release --notes "$(cat notes.md)"   # beta (published as prerelease)

Step 0 is scripts/release_quality_gate.sh: a Release-configuration compile that fails on high-risk concurrency/Sendable warnings, plus (stable only) the localization audit — fix the reported issue, don't bypass the gate; it exists so a known-bad build never burns an archive + notarization slot. Signing needs the Developer ID Application: Artur Rok (N529W98U62) certificate and the BetterCmdTabNotarization notarytool profile. Without them use --skip-notarization (dev build only — it refuses --auto-release).

Artifacts land in build/release/. Each build stamps a fresh CURRENT_PROJECT_VERSION (app target only); --skip-build-bump disables that.

5. If publishing manually

When not using --auto-release:

gh release create <tag> -R rokartur/BetterCmdTab \
  --title "BetterCmdTab <version>" --notes-file notes.md   # add --prerelease for betas

Complete when: the GitHub release exists with the notarized artifacts attached and the notes match the release-changelog format.

---name: releasedescription: Ship a BetterCmdTab release end to end. Use when the user wants a new version or beta published on GitHub.---# Release runbookOne command does the heavy lifting; this skill is the order of operations andthe failure points around it.## 1. PreflightWorking tree clean on `main`, and the unit suite green:```bashxcodebuild -scheme "BetterCmdTab Debug" -destination 'platform=macOS' test````scripts/set_version.sh --show` prints the current version. `MAJOR` tracksthe macOS year; tags are bare (`26.4.3`, `26.0-beta.1` — no `v` prefix on newtags).## 2. Bump the version (stable releases)```bashscripts/set_version.sh <version> # sets MARKETING_VERSION and auto-commits "chore: bump …"```Skip for betas — `build_release.sh --beta` derives the next `beta.N` fromexisting GitHub tags itself.## 3. Write the notesProduce the release body with the `release-changelog` skill and save it to afile (e.g. `notes.md` in the scratchpad). The body **is** the GitHub Releasedescription; its headings are parsed by `build_release.sh`, so the canonicalstructure from that skill is mandatory.## 4. Build, sign, notarize, publish`--notes` takes the notes **text**, not a path — pass the file through `cat`or the literal filename becomes the release body:```bashscripts/build_release.sh --auto-release --notes "$(cat notes.md)" # stablescripts/build_release.sh --beta --auto-release --notes "$(cat notes.md)" # beta (published as prerelease)```Step 0 is `scripts/release_quality_gate.sh`: a Release-configuration compilethat fails on high-risk concurrency/Sendable warnings, plus (stable only) thelocalization audit — fix the reported issue, don't bypass the gate; it existsso a known-bad build never burns an archive + notarization slot. Signingneeds the `Developer ID Application: Artur Rok (N529W98U62)` certificate andthe `BetterCmdTabNotarization` notarytool profile. Without them use`--skip-notarization` (dev build only — it refuses `--auto-release`).Artifacts land in `build/release/`. Each build stamps a fresh`CURRENT_PROJECT_VERSION` (app target only); `--skip-build-bump` disablesthat.## 5. If publishing manuallyWhen not using `--auto-release`:```bashgh release create <tag> -R rokartur/BetterCmdTab \ --title "BetterCmdTab <version>" --notes-file notes.md # add --prerelease for betas```**Complete when:** the GitHub release exists with the notarized artifactsattached and the notes match the release-changelog format.

Frequently asked questions

Release