-
Verify branch and pull latest:
git branch --show-current
If not on master, abort with an error. Then pull:
git pull
-
Run tests — abort if any fail:
uv run pytest
-
Parse current version from pyproject.toml:
Read pyproject.toml and extract the current version value.
-
Bump version in pyproject.toml:
Edit pyproject.toml to set the new version (without the v prefix).
-
Rebuild uv.lock:
uv lock
-
Analyze git history since last release:
git log --oneline v{OLD_VERSION}..HEAD
(Use the old version tag. If the tag doesn't exist, use git log --oneline with a reasonable range.)
-
Write CHANGELOG.md entry:
- Read
CHANGELOG.md.
- Insert a new entry after the
# Changelog header (before the first ## entry) with this format:
## v{NEW_VERSION} — {YYYY-MM-DD}
- Brief, user-facing summary of changes (new features, fixes, improvements)
- One bullet per logical change
- Skip internal refactors, CI tweaks, and dev-only changes unless significant
- Keep entries concise — focus on what a user would care about.
-
Show the new CHANGELOG entry and ask the user to confirm:
Display the new entry text and ask: "Does this changelog look good? Ready to tag and push?"
Wait for confirmation before proceeding. If the user wants edits, make them and re-confirm.
-
Commit, tag, and push:
git add pyproject.toml uv.lock CHANGELOG.md
git commit -m "Bump version to v{NEW_VERSION} and add changelog"
git tag v{NEW_VERSION}
git push
git push origin v{NEW_VERSION}
-
Watch the GitHub Actions build in the background:
The GitHub Actions workflow creates the release automatically from the tag. Do NOT run gh release create or gh release edit.
gh run watch $(gh run list --limit 1 --json databaseId -q '.[0].databaseId')
Run this with run_in_background: true so the user isn't blocked. When notified of completion, report the build result.
-
Report success with the new version and tag.