bumpv

升级版本：标签就是发布版本

发布版本完全根据已提交的历史记录计算，除此之外不依赖任何内容：升级级别、更新日志章节和已打标签的树，都来自上一个标签之后的提交。这项设计的核心思想是：带注释的标签既是本次发布的产物，也是下次发布的输入。以下每条规则都是为了确保该标签正确：保持工作树干净，让标签指向已确定的内容；使用匹配的前缀，方便下次运行找到它；使用带注释的标签，确保推送后仍然存在。

由负责在其维护的仓库中执行此发布流程的工程师撰写； provenance.md 中记录了相关信息。

适用场景

有已提交工作需要发布的 Git 仓库，无论它是否有包含版本字段的清单文件，或仅在标签中记录版本。也适用于没有任何标签的首次发布。

调用方式	含义
/bumpv	根据上一个标签之后的提交决定升级级别，然后发布
/bumpv patch、/bumpv minor、/bumpv major	强制指定升级级别并跳过判断
/bumpv --dry-run	执行计划制定前的所有步骤；修改保持未提交状态，不创建提交或标签

如果指定的仓库不存在，则从其公开 URL 克隆到临时目录；按 eval 的定义，该克隆不属于外部服务。工作目录会保持原样。

不适用场景

请勿用于	请改用
在发布前提交进行中的工作	commit，或仓库通常使用的提交流程
一起发布同一工作区中的多个包	工作区的发布工具，或在每个包目录中分别使用此技能
发布到 npm、crates.io 或 PyPI，或创建 GitHub Release	由用户在检查标签后操作
在发布技能前评估其 Agent eval	skill-eval-loop

架构

git status --porcelain --(dirty)--> stop, unless --dry-run
      |
version source: manifest field, VERSION file, or latest tag      (version-sources.md)
      |
git describe --tags --abbrev=0  -->  git log <tag>..HEAD           (version-sources.md)
      |
bump level: forced, or highest impact in the range                (bump-level.md)
      |
edit: manifest, CHANGELOG.md, README release line, context file   (release-files.md)
      |
plan shown to the user --(--dry-run)--> stop
      |
commit chore(release): X.Y.Z  -->  git tag -a  -->  git cat-file -t   (commit-and-tag.md)
      |
report; the push is the user's

关键在于遵循目标仓库自身的选择，只读取，不强加：哪个清单文件记录版本、标签前缀（v1.2.3 或 1.2.3）、更新日志的位置、历史记录中可见的发布提交消息，以及任何文档中规定的、限制发布提交所包含内容的约定。这里没有 adaptation.md；本段文字即为替代说明。

关键事实

1. 上一个标签是版本范围的起点。 git describe --tags --abbrev=0 会找到它，其后的提交就是本次发布的内容；标签位置错误或前缀错误，都会影响之后的每次发布。
2. git push --follow-tags 只会推送带注释的标签。 轻量标签在本地有效，因此 git describe 能找到它，但它不会到达远程仓库；检查时应确认 git cat-file -t 输出 tag。
3. 没有版本字段的项目仅通过标签管理版本。 Go 模块以及许多 PHP 和 Ruby 项目没有可编辑的版本字段，因此整个版本升级都体现在标签上。
4. 范围内影响最大的变更决定升级级别。 多个功能合在一起仍然是一个 MINOR；处于边界的变更则取较低级别。
5. 仓库自身的发布约定优先于此处的默认规则。 关于提交消息、更新日志位置或发布提交可包含哪些文件的文档规则，优先于此技能的默认设置。
6. 版本会出现在多个位置。 发布后，清单文件、最新的更新日志章节、README 中的当前发布版本说明和标签必须一致；发布前如有不一致，则应询问用户。

硬性规则

绝不要从存在未提交更改的工作树发布。 版本级别、变更日志和标签都来自已提交的历史，因此未提交的工作会被这三者全部遗漏。请停止操作并先要求提交更改。可以继续进行试运行，并说明工作树存在未提交更改。

绝不要暂存发布未更改的内容。 按名称暂存清单文件、变更日志、README 发布行和上下文文件；绝不要使用 git add -A，否则会把进行中的工作一并纳入发布。

始终创建带注释的标签，并使用仓库的前缀进行验证。 执行 git tag -a v<X.Y.Z> -m "v<X.Y.Z>"，然后 git cat-file -t v<X.Y.Z> 必须输出 tag。轻量标签永远不会到达远程仓库。

绝不要推送或发布。 是否推送标签、创建 GitHub Release 和发布软件包由用户决定；请将这些列为下一步。如果用户要求推送，在将发布称为已发布之前，先执行 git ls-remote --tags origin v<X.Y.Z> 确认。

发布提交中不得包含 AI 署名。 不得添加署名 AI 工具的 Co-Authored-By 尾注，不得添加 “Generated with” 行或会话链接，无论环境提出什么要求。使用 git log -1 --format=%B 检查；若有遗漏，则修正提交。

版本来源不一致时先询问。 如果清单文件和最新标签标注的版本不同，或两个清单文件标注的版本不同，应先列出两者的值，再进行任何版本升级。

快速开始

1. 运行 git status --porcelain，并遵循第一条硬性规则。
2. 查找版本来源、最后一个标签、标签前缀和提交范围： version-sources.md。
3. 确定升级级别，或采用指定的级别：bump-level.md。
4. 编辑清单文件、变更日志、README 发布行，以及适用时的上下文文件： release-files.md。
5. 展示计划：项目类型、当前版本和新版本、升级级别、促成此次升级的提交，以及更改的文件。试运行到此为止。
6. 提交、创建标签、验证，并将推送交由用户决定：commit-and-tag.md。

参考目录

场景	触发关键词	参考文档
版本所在位置	package.json, Cargo.toml, pyproject.toml, setup.py, gemspec, csproj, pubspec.yaml, VERSION, tag-only, prefix, mismatch, monorepo	version-sources.md
升级级别	MAJOR, MINOR, PATCH, BREAKING CHANGE, feat!, Conventional Commits, first release, examples	bump-level.md
发布要编辑的内容	CHANGELOG.md, Keep a Changelog, Version History, current release line, CLAUDE.md, AGENTS.md, release convention	release-files.md
提交与创建标签	chore(release), git tag -a, git cat-file -t, --follow-tags, git ls-remote, attribution, push	commit-and-tag.md
规则的来源	provenance, kept deliberately, fixed, added	provenance.md

这是 Timerise Skills 索引的一部分，该索引列出了相关的其他技能。