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.
中文简介正在准备中。当前显示原文说明。
查看安装方法安装前可以查看交给 AI 代理的指令内容。
Determine the next version from commit history when preparing a release. The highest-impact release-relevant commit drives the bump.
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.
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 tagThe 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 |
--apply) — update version file and optionally tagNever auto-apply version changes without user confirmation.
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:
For versions 0.y.z (pre-stable):
0.y.z until the project declares stability| 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 |
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
User asks for design, planning, or approach exploration before implementation. Covers new features, components, refactors, or architecture decisions. Creates design docs and proposes approaches with trade-offs.
中文简介正在准备中。当前显示原文说明。
Use when starting work in a repository under repositories/ that may lack CI configuration. Detects missing CI workflows (GitHub Actions, GitLab CI, CircleCI) and alerts the user to add one. Skips repos marked as research-only.
中文简介正在准备中。当前显示原文说明。
Use when the user asks to measure command execution time or optimize a feedback loop. Records explicit measurements and recommends faster alternatives such as unit tests versus integration tests. It is opt-in; it does not run on every command.
中文简介正在准备中。当前显示原文说明。
Team conventions for Python development — credentials, API clients, LLM response parsing, testing patterns, and data pipeline structure. Covers dotenv loading, retry logic, secret validation, and pipeline anti-patterns.
中文简介正在准备中。当前显示原文说明。
Measurement-driven code refactoring — profile before changing, measure after, keep only if metrics improve. Covers complexity reduction, extraction patterns, and bulk refactoring for mechanical changes across many files.
中文简介正在准备中。当前显示原文说明。
Scan projects for credential leaks, secrets in code, insecure patterns, LLM API key exposure, PII leakage to external AI services, and .env/.gitignore misconfigurations. Especially useful for data and API integrations, regardless of implementation language.
中文简介正在准备中。当前显示原文说明。