Use when cutting a stable/production release of THIS project. Fires on: "cut a release", "bump the version", "tag a release", "ship to prod", "release notes". Determines the semver bump from merged PRs, updates version files, generates a changelog, and tags. Distinct from bump-deps (incoming deps vs outgoing version).
SkillScore73Maintained
Automatic
◆DevOps & SRE pack
Last verified 8/6/2026
What it changes
Passed 15 of 20 test cases with the skill, and 12 of 20 without it.
Without skill59%
With skill73%
Checks it passed that the model alone missed
Consult .skills/change-map.yaml for project version couplings.
Prompt for user confirmation prior to pushing the tag to remote.
List commits and merged pull requests specifically since the last release tag.
3 fixed13 passed either way6 still failing0 broke
Pass-rate lift
+14 pp
Tokens
-31%
Agent turns
0%
Response time
-49%
Model gemini-3.6-flashMeasured 8/6/2026v116 of 22 cases passed with skill · 20 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 3
Prompt
We have finalized version 2.1.0 and created the local tag. Go ahead and push the tag to origin to launch the production deployment.
What was checked, without and with the skill
Checked
Without skill
With skill
Prompt for user confirmation prior to pushing the tag to remote.
Missed
Passed
case-05 · gemini-3.6-flash · 8/6/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md27 linessingle file
release-version — cut a stable outgoing version
This is about the project's OWN version, not its dependencies. Reproducible and
deliberate — production cadence, not a routine merge.
Procedure
Find the last release: the latest tag / version file value.
Gather the delta: list merged PRs / commits since that tag.
Decide the bump (semver): breaking change → major, new feature → minor,
fix only → patch. State the reasoning from the delta; ask the user if the
delta is ambiguous rather than guessing major/minor.
Update version files: bump every place the version is declared (manifest,
about screen, __version__, etc.). Consult .skills/change-map.yaml for a
"project version" coupling if present.
Changelog: generate a human-readable changelog section from the delta,
grouped (Added / Changed / Fixed). Link PRs.
Green gate: confirm the default branch is green before tagging — never tag
a red build.
Tag: create the annotated tag. Pushing the tag / triggering the prod
deploy is outward-facing — confirm with the user before pushing.
Output
The chosen version + why, the changelog section, files bumped, and the tag
command (executed only after the user confirms the push). Stop before any
irreversible publish step and ask.
Use when a repository artifact is about to record WHOSE data a tool was run against — an employer's or client's repo name, package path, hostname, ticket key, or domain vocabulary — in docs, commit messages, PR bodies, tests or fixtures. Fires on: "we proved it on <real repo>", "обезличь", "убери упоминания", "anonymize this", "is this safe to commit", "can this be public", writing a fixture modelled on real data, or a status/architecture note about a production run. Produces the de-identified w