Semantic versioning

Skill tuliosousapro/SaaS-blueprint/skills/semantic-versioning

Manages project versioning following Semantic Versioning (SemVer) principles. Calculates increments based on changes and synchronizes version across documentation and metadata. Use when the user asks to "bump the version", "prepare a release", or when the `changelog` skill calls for a release.From its SKILL.md

Install

npx -y skills add tuliosousapro/SaaS-blueprint --skill semantic-versioning

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

1.8 KB, 398 tokens by cl100k_base, as published. Nobody here has run it

Semantic Versioning Skill

Instructions

1. Detect Current Version

Read the latest version from CHANGELOG.md (e.g., the most recent header ## [X.Y.Z]).
Read the version from .github/repository-metadata.json.
If they differ, flag the mismatch to the user and ask which is authoritative.

2. Analyze Changes

Scan the changes since the last release:

If using changelog skill: Look at the items under [Unreleased] or the new version block being prepared.
If using git log: Scan for Conventional Commits types.

3. Determine Increment Type

Follow these priority rules:

MAJOR (X.0.0): Any "BREAKING CHANGE" footer or ! after the type (e.g., feat!:).
MINOR (x.Y.0): Any feat commit or "Added" entry in the changelog.
PATCH (x.y.Z): Any fix, perf, refactor commit or "Fixed"/"Changed" entry in the changelog.
No Change: If only docs, chore, style, test, build, or ci changes are found, default to PATCH unless the user specifies otherwise.

4. Apply Version Update

Update the following files in a single pass:

CHANGELOG.md: Rename the ## [Unreleased] section to ## [NEW_VERSION] - CURRENT_DATE or update the latest entry.
.github/repository-metadata.json: Update the "version" field.

Quality Gates

Version follows MAJOR.MINOR.PATCH format.
No regression in version number.
All version-tracking files are synchronized.
Date in CHANGELOG.md is in YYYY-MM-DD format.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most release versioning skills give in 398 tokens

Counted across 88 of the 111 authors here whose files we hold, read 2026-09-06

Generate the changelog from commits since the last tagin 16 of 88, across 9 files
Track release progress with a todo listin 12 of 88, across 5 files
Bump the version and push tagsin 12 of 88, across 5 files
Create a release branch and open a pull requestin 11 of 88, across 4 files
Run tests, lint, and build before opening the release PRin 11 of 88, across 4 files
Initialize a hierarchical swarm for release coordinationin 11 of 88, across 4 files
Create draft releases before publishingin 9 of 88, across 3 files
Deploy through staged progressive rolloutin 9 of 88, across 3 files
Cherry-pick critical fixes onto a hotfix branchin 8 of 88, across 2 files
Monitor rollout metrics and roll back automatically on failurein 8 of 88, across 2 files
Ask the user when the version bump type is unclearin 8 of 88, across 7 files
Create a GitHub release with formatted notesin 8 of 88

Said here and by no other author read

Flag version mismatches and ask which source is authoritative
Scan changes since the last release
Classify increment from commit types or changelog entries
Apply MINOR bump for feature commits
Apply PATCH bump for fixes, perf, and refactors
Default to PATCH for docs, chore, style, test, build, ci changes

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.