mcpField
R
release-notes

release-notes

github.com/thatrebeccarae开发194102 次安装25 周前更新
代码仓库

关于 release-notes

这是一个 Claude skill，可将 Git 历史整理为分类变更日志条目并创建 GitHub Release，适用于日常发布或补写历史记录；写入和发布前均需人工确认。

主要功能

  1. 01根据提交和已合并 PR 生成条目
  2. 02按变更类别整理日志
  3. 03建议语义化版本号
  4. 04生成完整历史变更日志
  5. 05写入或发布前要求确认

适用场景

  1. 01发布前准备变更说明
  2. 02更新月度变更日志
  3. 03为旧仓库补建变更日志

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/thatrebeccarae/claude-marketing --skill release-notes

安装后在 Claude Code 中输入/release-notes确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

EXAMPLES.md
LICENSE
REFERENCE.md

详细介绍

release-notes

根据 Git 历史生成变更日志条目和 GitHub 发行版。

安装

claude skill add --from https://github.com/thatrebeccarae/claude-skills/release-notes

适用场景

  • 发布新版本：你已有准备发布的提交，需要生成变更日志条目和/或 GitHub 发行版。
  • 每月更新变更日志：你按固定周期维护变更日志，需要汇总自上次条目以来的所有变更。
  • 追溯生成变更日志：现有项目没有 CHANGELOG.md，你想根据完整 Git 历史生成变更日志。

用法

生成变更日志条目
/release-notes changelog [repo-path]

读取自上一个标签以来的提交，为其分类，并将新条目插入 CHANGELOG.md 文件的开头。

创建变更日志条目和 GitHub 发行版
/release-notes release [repo-path] [version]

执行 changelog 的所有操作，然后通过 gh release create 创建 GitHub 发行版。如果未提供 version，则根据检测到的变更建议一个版本号。

追溯生成完整变更日志
/release-notes init [repo-path]

遍历完整的标签历史（若没有标签，则遍历完整提交历史），并从头生成完整的 CHANGELOG.md。

操作流程

步骤 1 — 查找上一个标签或发行版

运行 git describe --tags --abbrev=0 查找最近的标签。如果不存在标签，则使用初始提交作为起点。再通过 gh release list --limit 1 进行交叉核对，检查 GitHub 发行版是否与本地标签不同。

步骤 2 — 收集自上一个标签以来的提交
git log <last-tag>..HEAD --pretty=format:"%H %s" --no-merges

解析每条提交消息中的约定式提交前缀（type(scope): description）。对于不符合约定格式的提交，记录其原始消息。

步骤 3 — 检查已合并的 PR
gh pr list --state merged --search "merged:>YYYY-MM-DD" --json number,title,labels,mergedAt --limit 200

使用上一个标签的日期作为截止时间。将 PR 标题与提交消息进行交叉核对，以避免重复。PR 标题通常比提交消息更清晰——如果某条提交对应一个已合并的 PR，则优先使用 PR 标题。

步骤 4 — 为变更分类

将每条提交或 PR 归入某个变更日志类别：

前缀 / 信号类别
feat、feature新增
fix修复
正文中包含 BREAKING CHANGE 或带有 ! 后缀（例如 feat!:）破坏性变更
docs文档
refactor、perf变更
chore、ci、build维护
deprecate弃用
remove移除
security安全

未使用约定式提交时：分析提交消息内容以推断类别。查找诸如“add”“fix”“remove”“update”“refactor”“document”之类的关键词。将含义模糊的提交归入变更，并标记以供人工审核。

步骤 5 — 建议版本升级幅度

遵循语义化版本规则：

  • 如果存在任何破坏性变更，则进行主版本升级。
  • 如果存在新增条目且没有破坏性变更，则进行次版本升级。
  • 如果只有修复、变更或维护条目，则进行补丁版本升级。

提供建议并说明理由。最终版本由人工决定。

步骤 6 — 编写变更日志条目

使用 Keep a Changelog 格式：

## [X.Y.Z] — YYYY-MM-DD

### Breaking Changes
- Description of breaking change (#PR)

### Added
- Description of new feature (#PR)

### Fixed
- Description of bug fix (#PR)

### Changed
- Description of refactor or improvement (#PR)

### Documentation
- Description of docs change (#PR)

### Maintenance
- Description of chore (#PR)

省略空类别。类别顺序按上文所示排列——破坏性变更始终排在最前面。

步骤 7 — 人工审核

向用户展示格式化后的条目和建议版本。等待用户明确批准后再写入任何内容。标出所有分类含义模糊的提交。

步骤 8 — 写入 CHANGELOG.md

将新条目插入文件标题之后。绝不覆盖或重新排列现有条目。如果 CHANGELOG.md 不存在，则使用标准标题创建该文件：

# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
步骤 9 — 可选：创建 GitHub 发行版

仅当用户调用 /release-notes release 或明确提出请求时：

gh release create vX.Y.Z --title "vX.Y.Z" --notes "RELEASE_BODY"

使用变更日志条目作为发行说明正文。未经用户确认，绝不创建发行版。

核心原则

  1. 绝不自动发布。 每次发布和每次写入变更日志都必须获得明确的人工批准。
  2. 保留现有条目。 绝不修改、重排或删除之前的变更日志条目。
  3. 可读性优先于机器可解析性。 编写的描述应让阅读变更日志的人能够理解，而不是为了方便解析器处理。优先使用通俗语言，而不是提交哈希。
  4. 注明 PR 和作者。 将 PR 编号作为链接包含在内。对于有多位贡献者的项目，可以考虑注明首次贡献者。
  5. 有疑问时就询问。 如果某次提交含义不明确，应将其交由用户处理，而不是猜测类别。

评论

支持 Markdown