| name | make-release |
| description | Cut a new Whistler release. Bumps the version in whistler.asd, verifies all examples compile, generates release notes, commits, tags, and pushes. Use when asked to "release", "cut a release", "bump version", or "tag a new version". |
| argument-hint | [version] |
| disable-model-invocation | true |
| allowed-tools | Bash Read Edit Write Grep Glob |
Release Whistler
Follow these steps exactly, stopping on any failure.
0. Anchor at the repo root
Every subsequent shell command assumes the current directory is the
top of the Whistler checkout. If the slash command was invoked from
elsewhere, make and the examples/ lookups fail. Do this once at
the start:
cd "$(git -C "$CLAUDE_PROJECT_DIR" rev-parse --show-toplevel 2>/dev/null \
|| git rev-parse --show-toplevel)"
If that fails (not inside a git repo at all), stop and ask the user
to run the command from inside the Whistler checkout.
1. Determine version
If the user provided a version ($ARGUMENTS), validate that it matches MAJOR.MINOR.PATCH where each component is a non-negative integer (e.g. 1.7.0). If it doesn't, stop and tell the user.
If no version was provided, suggest one:
- Read the current version from
:version in whistler.asd.
- Review commits since the last tag:
git log $(git describe --tags --abbrev=0)..HEAD --oneline
- Apply semver rules:
- MAJOR bump: commits contain breaking changes (removed features, changed APIs, incompatible behavior)
- MINOR bump: commits add new features, new surface-language forms, new loader capabilities
- PATCH bump: commits are only bug fixes, documentation, or internal improvements
- Present the suggested version with a one-line rationale and ask the user to confirm or override.
Use the confirmed version as VERSION for all subsequent steps.
Check the tag doesn't already exist:
git tag -l "vVERSION"
If output is non-empty, stop — this version has already been released.
Ensure clean working tree:
git status --porcelain
If there are staged or unstaged changes to tracked files, stop and ask the user to commit or stash first.
Then check untracked files. If any look like they don't belong in the repo (log files, binaries, build artifacts, temp files, editor backups, etc.), list them and ask the user whether to clean up, add to .gitignore, or proceed anyway. Benign untracked files (e.g. .claude/, local config) are fine to ignore silently.
Verify git identity:
git config user.email
If the result is not green@moxielogic.com, stop and tell the user their git email is misconfigured for this repository.
Ensure we're on main and synced with remote:
git branch --show-current
git fetch origin main
git rev-list HEAD..origin/main --count
If the branch is not main, or there are upstream commits not yet pulled, stop and tell the user.
Check CI is green on HEAD:
gh run list --branch main --limit 1 --json conclusion --jq '.[0].conclusion'
If the result is not success, stop and warn the user that CI is failing on main. Ask whether to proceed anyway.
2. Update version
Edit whistler.asd and set every :version "…" line to VERSION.
There are five — one per defsystem (whistler, whistler/loader,
whistler/cli, whistler/symbolize, whistler/bpftrace). They must
stay aligned.
3. Verify all examples compile
make clean && make 2>&1 | tail -3
Run each example through the compiler:
for f in examples/*.lisp; do
echo "Compiling $f ..."
sbcl --noinform --non-interactive \
--eval '(require :asdf)' \
--eval '(push #P"." asdf:*central-registry*)' \
--eval '(asdf:load-system "whistler")' \
--eval "(whistler::compile-file* \"$f\" \"/tmp/$(basename "$f" .lisp).bpf.o\")" \
2>&1
done
If any example fails to compile, stop and report the failure. Do NOT continue.
4. Run the test suite
XDG_CACHE_HOME=/tmp/.cache make test
If any tests fail, stop and report the failure. Do NOT continue.
5. Add a CHANGELOG entry
Prepend a new section to CHANGELOG.md directly under the top-level
heading. Format:
## VERSION — YYYY-MM-DD
### New Features
...
### Bug Fixes
...
Use today's date. To decide what goes in the section, diff against the
most recent tag:
git log $(git describe --tags --abbrev=0)..HEAD --oneline
Include ONLY user-facing changes:
- Bug fixes
- New features
- Breaking changes (if any)
Do NOT include internal changes (refactors, lint fixes, doc updates, CI changes, directory reorganization). Those are visible in the git log for anyone who needs them.
Match the voice and heading style of previous entries already in CHANGELOG.md.
6. Commit
git add whistler.asd CHANGELOG.md
git commit -m "Bump version to VERSION"
7. Tag and push
Ask the user for confirmation before pushing, then:
git tag -s vVERSION -m "Release VERSION"
git push origin main
git push origin vVERSION
Pushing the tag triggers GitHub Actions which automatically builds the binary, creates the GitHub release, and attaches the artifact.