semantic-versioning
Skill17 starsChanged 59 days agoMITView on GitHub
Use when committing or pushing changes and the repository needs a version bump. Analyzes commits using conventional commit prefixes to determine whether the next release is a major, minor, or patch increment. Also use when the user asks about versioning, release planning, or changelog generation.
5 other projects use a version of this.
Adopted by
Most recently taken up by
- nledford/engineering-review-boardtheir own version, first seen Nov 3, 2026
- open-sdr/openwifitheir own version, first seen Oct 8, 2026
- Abdox-menara/guard-skillstheir own version, first seen Aug 24, 2026
- codecharmhq/claude-code-skillstheir own version, first seen May 17, 2026
- ffsshhttiikk/opencode-agents-skillstheir own version, first seen Feb 28, 2026
Other versions5 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 5
- open-sdr/openwifi★ 4.9ksame name
- nledford/engineering-review-board★ 11same name
- ffsshhttiikk/opencode-agents-skills★ 2same name
- codecharmhq/claude-code-skills★ 1same name
- Abdox-menara/guard-skills★ 0same name
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 repository9 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- brainstormingSkill
- ci-guardSkill
- cost-speed-meterSkill
- python-patternsSkill
- refactoring-patternsSkill
- security-checkSkill
- update-docsSkill
- verification-loopSkill
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 4 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 13
Before or after pushing changes (suggest the version bump)
- Distinctive: line 14
When the user asks "what version should this be?"
- Distinctive: line 15
When preparing a release or tag
- Distinctive: line 16
When reviewing a set of commits for release notes
- Distinctive: line 32
Run the analysis script:
- Distinctive: line 60
Never auto-apply version changes without user confirmation.
- Distinctive: line 74
If commits don't follow conventional format, fall back to keyword analysis:
- Very specific: line 84
Use 0.y.z until the project declares stability
“Common” is measured: kept by at least 6 in 10 of the 4 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
Determine the next version from commit history when preparing a release. The highest-impact release-relevant commit drives the bump.
When to Activate
- Before or after pushing changes (suggest the version bump)
- When the user asks "what version should this be?"
- When preparing a release or tag
- When reviewing a set of commits for release notes
Version Rules
Follows Semantic Versioning 2.0.0:
| Bump | Trigger | Examples |
| Major (X.0.0) | Breaking change | feat!:, fix!:, BREAKING CHANGE: in body/footer |
| Minor (x.Y.0) | New feature | feat:, feature: |
| Patch (x.y.Z) | Everything else | fix:, chore:, docs:, style:, refactor:, test:, ci:, perf: |
The highest bump wins: if any commit is major, the release is major — regardless of how many patches are in the batch.
How to Check
Run the analysis script:
uv run skills/semantic-versioning/scripts/version-bump.py [repo-path]Options:
--apply— update the version file after confirmation--tag— also create a git tag
Version File Detection
The script auto-detects where the version lives:
| File | Field |
pyproject.toml | [project] version = "x.y.z" |
package.json | "version": "x.y.z" |
Cargo.toml | [package] version = "x.y.z" |
VERSION | Plain text file |
Workflow
- Analyze — scan commits since last tag, classify each
- Report — show the bump type, commit breakdown, and suggested next version
- Confirm — wait for user approval before making changes
- Apply (if
--apply) — update version file and optionally tag
Never auto-apply version changes without user confirmation.
Commit Format Guide
For best results, follow conventional commits:
<type>[optional scope][!]: <description>
[optional body]
[optional footer(s)]If commits don't follow conventional format, fall back to keyword analysis:
- Words like "add", "new", "feature" → minor
- Words like "fix", "bug", "patch", "correct" → patch
- Words like "breaking", "remove", "drop", "rename API" → major
Pre-1.0 Semantics
For versions 0.y.z (pre-stable):
- API is considered unstable
- Minor bumps may include breaking changes
- Use
0.y.zuntil the project declares stability
Common Mistakes
| Mistake | Fix |
Bumping major for every feat! in pre-1.0 | Pre-1.0: breaking changes go in minor |
| Forgetting to tag after version bump | Always tag: git tag v<version> |
| Version in multiple files getting out of sync | Use the script to update all detected version files |
| Non-conventional commit messages | Fall back to keyword analysis, but encourage conventional commits |
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.

