| name | commit |
| description | Bump the project version, commit, and push in a clean OSS-friendly way, auto-detecting the version file across languages. Use when the user asks to "commit", "bump version", "push a version", or finishes a feature and wants it committed. Does NOT tag or publish a release — bumping and releasing are separate; if the user asks to "release"/"ship"/"publish a version", that's a release flow, not this skill. Do NOT use for plain `git commit` of work-in-progress with no intent to version or push. |
| allowed-tools | Bash(git:*) Bash(python:*) Read Edit Write |
| metadata | {"author":"lebrunthibault","version":"1.2.0"} |
Commit
The bump → commit → push flow, language-agnostic. You already know how to stage, write a clean
conventional-commit message, and push — this skill adds the three things that aren't obvious:
the concurrency guard, the deterministic version bump, and the push guardrails.
1. Guard against a concurrent commit
Before staging, check no other commit (another agent or terminal) is mid-write. Git's own lock
files are the signal — index.lock exists while staging/committing and is removed when done.
ls "$(git rev-parse --git-dir)"/index.lock "$(git rev-parse --git-dir)"/HEAD.lock 2>/dev/null
If a lock exists: stop, don't commit, don't delete it. Tell the user. (If it's clearly stale —
old timestamp, no running git — ask before removing.) Best-effort, not a hard mutex: if git itself
errors Unable to create '.../index.lock': File exists, treat it the same way.
2. Decide the bump, then apply it
Bump the version only when the change affects what the software does or exposes (new feature,
behavior change/removal, observable bug fix). Skip the bump for docs, tests, formatting, internal
refactors, CI/deps with no user-facing effect. Mixed change → the feature wins.
python scripts/detect_version.py detect
python scripts/detect_version.py bump <major|minor|patch>
- major breaking · minor new feature · patch bug fix.
- Confirm the bump with the user (old → new, which file) before writing.
{"file": null} → no version source. Offer to create a top-level VERSION file (plain 0.1.0),
then bump against it. See references/version-files.md.error about non-semver (e.g. 2.0.0rc1) → don't force it; ask for the target and edit by hand.
3. Commit & push
The version-file change goes in the same commit as the work. Conventional-commit subject
(feat:/fix:/docs:…), imperative, why in the body. Let hooks run — never --no-verify.
This skill never tags or git push --tags — that's the release flow's job (tagging on a v*
that CI releases from would publish on every bump). Push the commit only.
Push guardrails:
- Never
git push --force/--force-with-lease unless the user explicitly asks.
- Pushing straight to
main/master → mention it so the user can object.
- Never push secrets — if
git status showed .env, keys, creds: stop and confirm.
Notes
Version logic is delegated to scripts/detect_version.py (priority order + formats live there and
in references/version-files.md) so it's deterministic across runs.
