version-bump
Skill2 starsChanged 39 days agoBSD-3-ClauseView on GitHub
Determines appropriate semantic version bumps based on changes. Use when deciding version numbers, evaluating breaking changes, or planning releases. Triggers on terms like "version", "semver", "breaking change", "major/minor/patch".
26 other projects use a version of this.
Adopted by
Most recently taken up by
- MMACABRE/SKILLStheir own version, first seen Nov 8, 2026
- SamuelAlev/control-centertheir own version, first seen Nov 8, 2026
- marketcalls/openalgotheir own version, first seen Nov 2, 2026
- vladimiracunadev-create/claude-skills-toolkittheir own version, first seen Nov 1, 2026
- bostonaholic/skillstheir own version, first seen Oct 25, 2026
- susantedit/claude-skillstheir own version, first seen Oct 20, 2026
Used with
Projects with it also use security-audit and commit.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
CloudflareSkillsecurity-audit
Security guidance and vulnerability review for codebases, APIs, services, CLI tools, libraries, and daemons. Use for security questions, focused reviews, vulnerability research, security audits, or pen tests. Run the complete workflow only for explicit codebase audit or pen-test requests, full/comprehensive/end-to-end reviews, or requested report artifacts.
Also in 3 projects that use this
SentrySkillcommit
Create commit messages following Sentry conventions. Use when committing code changes, writing commit messages, or formatting git history. Follows conventional commits with Sentry-specific issue references.
Also in 3 projects that use this
Other versions26 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 26
- meteor/meteor★ 45ksame name
- BenedictKing/ccx★ 4ksame name
- marketcalls/openalgo★ 3ksame name
- swoosh/swoosh★ 1.5ksame name
- microsoft/roosterjs★ 1.3ksame name
- deadlock-mod-manager/deadlock-mod-manager★ 584same name
- Kindness-Kismet/Storage-redirection-X-Public★ 527same name
- Kindness-Kismet/One-Player★ 486same name
- feichai0017/QuillSQL★ 277same name
- novitalabs/pegaflow★ 221same name
16 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository15 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- changelogSkill
- commit-twiddleSkill
- format-tableSkill
- releaseSkill
- update-adr-inventorySkill
- update-snapshotsSkill
- changelogSkill
- commit-twiddleSkill
- format-tableSkill
- releaseSkill
- update-adr-inventorySkill
- update-snapshotsSkill
- version-bumpSkill
The file
We split this skill into the rules it gives an agent
8 rules. 0 are common, 7 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 23 edited versions we read keep these.
7
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 71
Use MINOR for breaking changes and new features
- Distinctive: line 72
Use PATCH for bug fixes, documentation, and refactoring without behavior changes
- Distinctive: line 81
Check for breaking changes:
- Distinctive: line 86
If breaking changes exist -> MINOR bump before 1.0.0.
- Distinctive: line 88
If new features exist -> MINOR bump
- Distinctive: line 90
If only fixes/refactoring -> PATCH bump
- Distinctive: line 94
When bumping version, update:
- Very specific: line 98
CHANGELOG.md: - Run python3 scripts/changelog.py collect --component crate --version X.Y.Z, which adds the ## [X.Y.Z] - YYYY-MM-DD section …
“Common” is measured: kept by at least 6 in 10 of the 23 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Semantic Versioning Skill
This skill helps determine appropriate version bumps following Semantic Versioning.
Version Format
MAJOR.MINOR.PATCH- MAJOR: Breaking changes
- MINOR: New features, backwards compatible
- PATCH: Bug fixes, backwards compatible
Version Bump Decision Tree
MAJOR (X.0.0) - Breaking Changes After 1.0
For versions at or above 1.0.0, bump MAJOR when you make incompatible API changes:
- Removed public functions, methods, or types
- Changed function signatures (parameters, return types)
- Renamed public APIs
- Changed default behavior that breaks existing usage
- Removed CLI flags or changed their meaning
- Changed configuration file format incompatibly
MINOR (X.Y.0) - New Features and Pre-1.0 Breaking Changes
Bump MINOR when you add functionality in a backwards compatible manner, or when you make a breaking change before 1.0.0:
- New commands or subcommands
- New CLI flags
- New configuration options
- New output formats
- New integrations or providers
PATCH (0.0.X) - Bug Fixes
Bump PATCH when you make backwards compatible bug fixes:
- Fix incorrect behavior
- Fix crashes or errors
- Performance improvements (no API changes)
- Documentation fixes
- Internal refactoring (no behavior changes)
Quick Reference
| Change Type | Version Bump |
| Breaking API change | MAJOR (≥1.0), MINOR (<1.0) |
| Removed feature | MAJOR (≥1.0), MINOR (<1.0) |
| New command/feature | MINOR |
| New CLI flag | MINOR |
| New provider/integration | MINOR |
| Bug fix | PATCH |
| Performance fix | PATCH |
| Documentation only | PATCH |
| Refactoring (no behavior change) | PATCH |
Pre-1.0 Versioning
For versions < 1.0.0 (like this project):
- Use MINOR for breaking changes and new features
- Use PATCH for bug fixes, documentation, and refactoring without behavior changes
Instructions
- Review all changes since last release:
git log --oneline $(git describe --tags --abbrev=0)..HEAD - Check for breaking changes:
- Removed or renamed public APIs?
- Changed default behaviors?
- Incompatible configuration changes?
- If breaking changes exist -> MINOR bump before 1.0.0; MAJOR bump from 1.0.0 onward
- If new features exist -> MINOR bump
- If only fixes/refactoring -> PATCH bump
Version Update Locations
When bumping version, update:
- Cargo.toml -
version = "X.Y.Z" - Cargo.lock - Refresh the
omni-devpackage version (for example, by runningcargo check) and include the lockfile change - CHANGELOG.md - Run
python3 scripts/changelog.py collect --component crate --version X.Y.Z, which adds the## [X.Y.Z] - YYYY-MM-DDsection from thechangelog.d/fragments - Version links -
collectupdates the comparison URLs at the bottom of CHANGELOG.md; check them
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.