Menu
Cut a new release — bump VERSION, build, open a PR, merge, tag, push, upload to GitHub and PyPI.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Stage unstaged changes into one or more atomic git commits with project-compliant commit messages
Stage unstaged working tree changes into one or more atomic commits with git-stage-batch. Use when the user wants Codex to split unstaged edits into a clean commit series with project-compliant commit messages. Do not use for already-staged changes or for generic git help.
Decompose unstaged working-tree changes into narrow concerns, peel them into git-stage-batch batches, rebuild as a fine-grained atomic commit series, or polish an already-built series
Decompose unstaged working-tree changes into a clean commit series by identifying narrow product, workflow, or architectural concerns, peeling them into git-stage-batch batches, rebuilding atomic commits, or polishing an already-built series.
Draft an algorithm-optimized tweet thread announcing the latest release.
Commit the current staged index as one project-compliant git commit. Use when the user has already staged the exact changes they want to commit and wants help inspecting that staged set, drafting a compliant message, and creating the commit. Do not use for splitting or staging unstaged changes.
| name | release |
| description | Cut a new release — bump VERSION, build, open a PR, merge, tag, push, upload to GitHub and PyPI. |
| whenToUse | Use this when the user wants to cut, publish, or ship a new release of the project. |
| allowed-tools | Bash(git *), Bash(gh *), Bash(uv run pytest *), Bash(uv build), Bash(uv publish), Bash(cat VERSION), Bash(ls dist/), Bash(rm -rf dist/), Read, Write, Edit |
| user-invocable | true |
Your task is to cut a new release of this project.
Ask the user for the new version number if they have not already provided one. The current version lives in the VERSION file at the repository root.
Before starting, verify:
git status --short produces no output).main branch.uv run pytest -n auto).If any check fails, stop and report the problem.
Follow these steps in order. Each step depends on the previous one succeeding. Confirm each step succeeded before moving on. If any step fails, stop and report the error — do not skip steps.
git checkout -b release-v<VERSION>
Write the new version string (without a v prefix, without a trailing newline) to the VERSION file. Commit with the message format:
project: Bump version to <VERSION>
The commit body should follow the project's three-paragraph commit-message convention (see CONTRIBUTING.md). Describe the current version state, why a bump is needed, and what this commit does.
rm -rf dist/
uv build
Verify a .whl and .tar.gz appeared in dist/.
git push -u origin release-v<VERSION>
Open a PR with gh pr create. The title should be Release v<VERSION>. The body should contain a changelog section summarizing user-visible changes since the previous release tag. Use the changes-since-last-release skill output if available in conversation context; otherwise generate a summary from git log.
gh pr merge --merge --delete-branch
After merging, update the local main branch:
git checkout main
git pull origin main
The project uses annotated tags on the merge commit (not lightweight tags). Find the merge commit on main and tag it:
git tag -a v<VERSION>
Use v for the Summary and for the message.
git push origin v<VERSION>
gh release create v<VERSION> --title "v<VERSION>" --notes "<changelog markdown>"
The release notes should match the PR body changelog section. Do not attach wheel or sdist artifacts to the GitHub release — those go to PyPI only.
uv publish
If credentials are not configured or upload fails, report the error and tell the user what command to run manually.
Report the final state: