Semantic versioning
Skill tuliosousapro/SaaS-blueprint/skills/semantic-versioning
BRAINIAC - SaaS Blueprint, NOT an APP. It's a comprehensive playbook and operating system designed for building, launching, and scaling a SaaS APP covering from MVP to Mass Scale. It is structured as a chronological and functional roadmap, containing over 80 specialized directories, each with its own PLAYBOOK.md.
npx -y skills add tuliosousapro/SaaS-blueprint --skill semantic-versioningAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 3 stars3 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.
What its author says it does
Copied from the file, not written here
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.
SKILL.md
1.8 KB, 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
changelogskill: 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
featcommit or "Added" entry in the changelog. - PATCH (x.y.Z): Any
fix,perf,refactorcommit or "Fixed"/"Changed" entry in the changelog. - No Change: If only
docs,chore,style,test,build, orcichanges 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_DATEor update the latest entry. - .github/repository-metadata.json: Update the
"version"field.
Quality Gates
- Version follows
MAJOR.MINOR.PATCHformat. - No regression in version number.
- All version-tracking files are synchronized.
- Date in
CHANGELOG.mdis inYYYY-MM-DDformat.