# Semver Automation > "Provides Automating semantic versioning in Git repositories for version bumping, changelog generation, and release automation using conventional commits and to" - Skill: `paulpas/semver-automation` (Agent Skill) - Install (CLI): `npx skillmds@latest add paulpas/semver-automation` - Raw SKILL.md: https://api.skillmd.com/api/skills/paulpas/semver-automation/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - License: MIT - Author: paulpas (https://skillmd.com/u/paulpas) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/paulpas/semver-automation --- # Semantic Versioning Automation Implementation guide for automating semantic versioning in Git repositories using conventional commits and release automation tools like semantic-release, including version bumping, changelog generation, and release workflows. ## TL;DR Checklist - [ ] Establish conventional commit format (feat:, fix:, BREAKING CHANGE:) for all commits - [ ] Configure semantic-release or similar tool in CI/CD pipeline - [ ] Set up automatic version bumping based on commit types - [ ] Generate changelogs automatically from commit messages - [ ] Create and push Git tags for each release - [ ] Publish artifacts and update version files automatically --- ## When to Use This Skill Use semver automation when: - Managing public libraries or frameworks with semantic versioning contract - Running continuous deployment with frequent releases - Multiple teams need consistent versioning across services - You want to reduce human error in version management - Changelogs should reflect actual commit history - Teams need clear communication about breaking changes - Automating release notes and changelog generation --- ## When NOT to Use This Skill Avoid full automation when: - Monolithic product with infrequent (quarterly) releases - Version numbers have business meaning beyond semver (e.g., "Q3 2026.1.0") - Manual changelog curation is important (mixed with non-code changes) - Organization prefers explicit version decisions (no automatic bumping) - Repository has inconsistent or legacy commit practices --- ## Semantic Versioning Format ``` MAJOR.MINOR.PATCH[-PRERELEASE][+BUILD] Examples: 1.0.0 - First stable release 1.2.3 - Patch fix (1.2.2 → 1.2.3) 2.0.0 - Breaking change (1.x.x → 2.0.0) 2.0.0-rc.1 - Release candidate 2.0.0-alpha - Alpha release 2.0.0+build-123 - Build metadata Increment rules: MAJOR when: Breaking changes / incompatible API changes MINOR when: New features (backward-compatible) PATCH when: Bug fixes (backward-compatible) ``` --- ## Conventional Commits ### Format ``` ():