| name | version |
| description | Bump the project version (major, minor, or patch) and add a changelog entry. Use when preparing a release, bumping versions, or the user says "/version". |
| allowed-tools | Read Edit Bash(git:*) |
Bump the project version using semver. Accepts one argument: major, minor, or patch.
Semver rules
Given a version MAJOR.MINOR.PATCH:
patch → increment PATCH, e.g. 0.4.6 → 0.4.7
minor → increment MINOR, reset PATCH, e.g. 0.4.6 → 0.5.0
major → increment MAJOR, reset MINOR and PATCH, e.g. 0.4.6 → 1.0.0
Files to update
package.json — top-level "version" field
CHANGELOG.md — new version section inserted at the top
Steps
-
If no argument is provided, ask the user which bump type they want (major, minor, or patch).
-
Read package.json to get the current version.
-
Compute the new version according to the semver rules above.
-
Tell the user: "Bumping version from X.Y.Z to A.B.C"
-
Update package.json using the Edit tool.
-
Run git log --format='%s%n%n%b' <last-bump-hash>..HEAD where <last-bump-hash> is the most recent commit matching chore: bump version to (find it with git log --oneline --grep='chore: bump version to' -1). If no such commit exists, use all commits from the beginning of history. Use the commit subjects and body descriptions as context to write a concise bullet-point list of significant changes for the new version entry.
-
Read CHANGELOG.md and insert a new version section immediately after the # Changelog heading (before the first existing ## entry) using the Edit tool:
## A.B.C
- Summary of change 1
- Summary of change 2
-
Report the updated version.
-
Stage the changed files and commit with the message: chore: bump version to A.B.C