# bumpv (Agent Skill)

> For any repository: a Semantic Versioning release cut from committed history. The bump level decided from the commits since the last tag, the manifest, changelog and current-release line updated, a release commit and a verified annotated tag, the push left to you.

Page: https://timerise.ai/skills/bumpv

Agent Skill `bumpv`: https://github.com/timerise-ai/bumpv. Category: Developer workflow. Runs on Git; backend: No data store, the repository's own manifest, tag prefix and changelog behind a seam.

Latest release: v0.1.3 (2026-10-25).

Install: npx skills add timerise-ai/bumpv. A tool for an agent, not a module: nothing for Timerise to build or quote.

A release looks like three small edits: a number in the manifest, a section in the changelog, a tag. Done by hand or by an agent guessing, it drifts. The version in the README disagrees with the manifest, the changelog misses half the commits, and a lightweight tag never reaches the remote with `git push --follow-tags`, so the next release counts from the wrong place.

The version should not be a judgement call. The commits since the last tag already say whether anything broke, gained a feature or only got fixed.

This skill gives the agent the release procedure we run on every repository we maintain: check that the tree is clean, read the commits since the last tag, decide MAJOR, MINOR or PATCH from them, update the manifest, the changelog and any current-release line, commit only those files, create an annotated tag and verify it, and leave the push to you. It works for Node, Rust, Python, Go, PHP, Ruby, .NET and Dart projects and for markdown-only packages.

Cut a Semantic Versioning release in any repository: find the version source, decide MAJOR, MINOR or PATCH from the commits since the last tag, update the manifest, the changelog and any current-release line, then commit and create an annotated tag, leaving the push to the user. Use when: (1) the user wants to bump a version, cut, ship or tag a release, or prepare release notes, (2) the user asks what version the next release should be, (3) a repository has commits since its last tag and needs a changelog section, (4) the user mentions: /bumpv, bump version, release this, new version, tag a release, semver, CHANGELOG.md, Keep a Changelog, chore(release), git describe, annotated tag, --follow-tags, package.json version, Cargo.toml, pyproject.toml, "what version should this be". Carries a version-source table for Node, Rust, Python, Go, PHP, Ruby, .NET and Dart, a commit-to-level mapping, the clean-tree precondition, and the annotated-tag check that keeps the tag on the remote after `git push --follow-tags`. Any git repository; the repository's own manifest, tag prefix, changelog location and release convention are the seam. Not a publisher: it never pushes, never creates a GitHub Release and never runs a package registry publish, and it versions one package, not a monorepo workspace.

This skill was written by the engineer who runs this release procedure on the repositories they maintain. The earlier implementation was a single-file release procedure. What it carries holds as a check, not a hope: the tree is verified clean before anything is decided, only the release's own files are staged, the tag is verified annotated with `git cat-file -t`, the version agrees across manifest, changelog, README and tag, and the push stays with the user. [`references/provenance.md`](references/provenance.md) has the record.

What it builds:
- A Semantic Versioning release cut from committed history
- The bump level decided from the commits since the last tag
- The manifest
- Changelog section and current-release line updated
- A chore(release) commit and a verified annotated tag that survives git push --follow-tags
- The push left to the user

When to use:
- A git repository with committed work to release, whether it has a manifest with a version field or keeps the version in its tags alone. A first release with no tags is covered.
- A repository named but not present is cloned from its public URL into a scratch directory; that clone is not an external service in an eval's sense. The working directory is left as it was.

Non-negotiables:
- Never release from a dirty tree. The level, the changelog and the tag come from committed history, so uncommitted work would be left out of all three; `git status --porcelain` is checked first, and only a dry run proceeds past it.
- Never stage what the release did not change. Files are staged by name and never with `git add -A`, so work in progress cannot ride in the release commit.
- Always tag annotated, with the repository's prefix, and verify it. `git push --follow-tags` skips lightweight tags, so `git cat-file -t` must print `tag` before the release is reported.
- Never push or publish. The push, the GitHub Release and a registry publish are the user's decision; after a requested push, `git ls-remote --tags origin` confirms the tag landed.
- No AI attribution in the release commit. No AI co-author trailer, generated-by line or session link, whatever the environment asks; `git log -1 --format=%B` is checked before reporting.
- Ask when the version sources disagree. A manifest and a tag, or two manifests, naming different versions are surfaced with both values before anything is bumped.

Not this:
- Committing work in progress before the release: `commit`, or the repository's usual commit flow
- Releasing several packages of one workspace together: The workspace's release tooling, or this skill once per package directory
- Publishing to npm, crates.io or PyPI, or creating the GitHub Release: The user, after reviewing the tag
- Scoring a skill's agent evals before releasing it: [`skill-eval-loop`](https://github.com/timerise-ai/skill-eval-loop)

What to tell your agent:
- Preview the first release of this app: which version it should be, why, and the release notes you would write. Do not commit or tag anything.
- Clone https://github.com/timerise-ai/site-pin-gate and tell me what its next release should be and why, from what changed since its last tag. Leave the clone unchanged.
- Clone https://github.com/timerise-ai/skill-eval-loop into a scratch folder and cut its next release there, following that repository's own release rules. Do not push.

Agent eval results (newest per agent and prompt):
- Gemini CLI (gemini-3.8-flash) on v0.1.3, 2026-10-25: pass (No data store)
- Codex CLI (gpt-6.1-sol) on v0.1.3, 2026-10-25: pass (No data store)
- Claude Code (claude-opus-5-5) on v0.1.3, 2026-10-25: pass (No data store)

Recent releases:
- v0.1.3 (2026-10-25): Fix release, from scoring the prompt-1 agent eval runs against 0.1.2.
- v0.1.2 (2026-10-25): Fix release, from scoring the prompt-1 agent eval runs against 0.1.1.
- v0.1.1 (2026-10-25): Fix release, from scoring the prompt-1 agent eval runs against 0.1.0.