| name | make-release |
| description | Cut a new Happening release. Bumps version in happening.asd, verifies the build, 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 Happening
Follow these steps exactly, stopping on any failure.
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. 0.4.0). If it doesn't, stop and tell the user.
If no version was provided, suggest one:
- Read the current version from
:version in happening.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 commands, new 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 master and synced with remote:
git branch --show-current
git fetch origin master
git rev-list HEAD..origin/master --count
If the branch is not master, or there are upstream commits not yet pulled, stop and tell the user.
Check CI is green on HEAD:
gh run list --branch master --limit 1 --json conclusion --jq '.[0].conclusion'
If the result is not success, stop and warn the user that CI is failing on master. Ask whether to proceed anyway.
2. Update version
Edit happening.asd and set :version to "VERSION".
3. Build
make clean && make 2>&1 | tail -10
If the build fails, stop and report the failure. Do NOT continue.
4. Generate release notes
Create docs/release-notes/RELEASE-NOTES-VERSION.md.
To decide what goes in the notes, diff against the most recent tag:
git log $(git describe --tags --abbrev=0)..HEAD --oneline
Check updated dependencies for noteworthy changes:
git diff $(git describe --tags --abbrev=0)..HEAD -- ocicl.csv
For each dependency that changed, especially security-critical ones like pure-tls, check the upstream changelog or commit history for user-facing changes (security fixes, new features, breaking changes). For example:
cd /home/green/git/pure-tls && git log --oneline --since="LAST_TAG_DATE" --until="NOW"
Surface important upstream changes in the release notes — particularly security fixes, which should get their own ## Security section with advisory IDs and descriptions.
Include ONLY user-facing changes:
- Security fixes (from dependencies or this project)
- Bug fixes
- New features
- Breaking changes (if any)
- Notable dependency updates (with version info)
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 format of previous release notes in docs/release-notes/. The standard format is:
# Happening VERSION Release Notes
**Release Date:** Month YYYY
## Summary
One-line summary of the release.
## New Features
### Feature Name
Description of the feature.
## Bug Fixes
- Description of fix.
## Breaking Changes
None (or list them).
## Upgrade Notes
Drop-in replacement for PREVIOUS_VERSION (or describe migration steps).
5. Commit
git add happening.asd docs/release-notes/RELEASE-NOTES-VERSION.md
git commit -m "Release VERSION"
6. Tag and push
Ask the user for confirmation before pushing, then:
git tag -s vVERSION -m "Release VERSION"
git push origin master
git push origin vVERSION
Pushing the tag triggers GitHub Actions which automatically builds the Linux binary and creates the GitHub release.
