semver-bump
Skill0 starsChanged 17 days agoMITView on GitHub
Recommend and apply a Semantic Versioning bump based on unreleased changes. Use when a project needs a major, minor, or patch version update and corresponding release notes; follow its existing conventions without committing or publishing by default.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- dlimkin/agent-skillstheir own version, first seen Sep 27, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- dlimkin/agent-skills★ 1same 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 repository13 other files it gives its agents.
- AGENTS.mdAGENTS.md
- diagram-aestheticsSkill
- engflow-clarifySkill
- engflow-code-reviewSkill
- engflow-designSkill
- engflow-handoffSkill
- engflow-implementSkill
- engflow-planSkill
- engflow-pocSkill
- engflow-refactor-assessSkill
- engflow-researchSkill
- engflow-specifySkill
- engflow-tasksSkill
The file
We split this skill into the rules it gives an agent
9 rules. About 0 are common, 9 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Read the project's instructions and versioning documentation.
- Distinctive: line 21
Do not assume branch names, file paths, tag formats, or a release baseline.
- Distinctive: line 22
Use local history, diffs, and relevant files to inspect changes.
- Distinctive: line 51
If evidence is ambiguous, ask for clarification instead of guessing.
- Distinctive: line 57
Verify that the relevant files and release baseline have not changed.
- Distinctive: line 58
Update the authoritative version and only the synchronized fields required by the project.
- Distinctive: line 60
Update the changelog using the project's format, if applicable.
- Distinctive: line 62
Check that the resulting version is valid SemVer, the required version fields agree, and the release notes match the selected changes.
- Distinctive: line 67
Default to read-only analysis.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
SemVer Bump
A prompt-only skill for updating Semantic Versioning versions. No helper scripts or dependencies are required. Branch integration and publication are outside this skill's scope.
1. Discover project conventions
Read the project's instructions and versioning documentation. Identify:
- The authoritative version source and any synchronized version fields.
- The current version, release baseline, and changes intended for this bump.
- The changelog location and format, if the project uses one.
- Any pre-1.0, prerelease, or release-specific rules.
Do not assume branch names, file paths, tag formats, or a release baseline. Use local history, diffs, and relevant files to inspect changes. If conventions conflict, the baseline is unclear, or the version is not SemVer, ask the user before proceeding. Do not silently adopt SemVer for another versioning scheme. Preserve existing local work; never automatically stash, reset, or clean it.
2. Recommend the bump
Review actual changes and public compatibility, not just commit titles. Use the highest required level across the changes intended for release:
| Level | Reason | Result from X.Y.Z |
| major | Incompatible public behavior or contract | (X+1).0.0 |
| minor | Backward-compatible new capability | X.(Y+1).0 |
| patch | Backward-compatible fix | X.Y.(Z+1) |
Conventional Commits, when used, provide evidence: breaking-change markers
suggest major, feat suggests minor, and fix suggests patch. Verify them
against the actual changes. Documentation and maintenance changes need a bump
only when the project's policy or released behavior warrants it. Effective
reverts or an empty change set may require no bump.
SemVer does not prescribe stable compatibility during 0.x; follow the project's
explicit policy or ask how breaking changes should be versioned. For prerelease
or build metadata, follow the project's rules or request the intended transition
rather than treating the version as a simple stable X.Y.Z.
Report the current version, baseline, recommended level and next version, and a brief rationale. If there is no release-worthy change, recommend no bump. If evidence is ambiguous, ask for clarification instead of guessing.
3. Apply only after confirmation
Once the user confirms the target version and authorizes edits:
- Verify that the relevant files and release baseline have not changed.
- Update the authoritative version and only the synchronized fields required by the project. Preserve formatting and unrelated content.
- Update the changelog using the project's format, if applicable. Include only the intended changes; do not invent a changelog or release date convention.
- Check that the resulting version is valid SemVer, the required version fields agree, and the release notes match the selected changes. Run relevant project checks and review the diff.
- Summarize the old and new versions, changed files, and validation results.
Default to read-only analysis. Do not fetch remotely, commit, integrate branches, create tags, or push as part of a bump. If the user separately requests those operations, follow the project's workflow and authorization rules; a version update alone is not permission to publish.
Examples
- "Recommend the next SemVer version without editing files."
- "Apply the confirmed minor bump and update the existing changelog; do not commit."
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.