changelog skill：让发版前的最后一件事不再拖延
发版前一小时，你在干什么
说实话，大多数开发者发版前的状态是：代码合并了，测试过了，tag 打好了，然后对着空白的 CHANGELOG.md 发呆。
不是不想写，是不知道从哪写起。Git log 翻了三页，有用的信息淹没在几十个 typo fix 和 formatting 提交里。最后憋出一句「修复若干问题，优化性能」，自己看着都心虚。
用户那边呢？他们打开更新日志，看到「bug fixes and improvements」，什么信息也没有，只能自己踩坑才知道哪里变了。
这不是小事。CHANGELOG 是用户信任的起点。写得清楚，用户敢升级；写得敷衍，用户下次看到版本号直接跳过。
changelog skill 是干什么的
OpenClaw 生态里没有「一个」changelog skill，而是一整个工具家族，各有分工。
我先说最实用的两个：
changelog-release-manager（作者 SKY-lv）：专门针对 Conventional Commits 规范的场景。你只要保证 commit 信息按 feat/fix/docs/refactor 格式写，它自动从 git history 里提取、分类、生成标准格式的 CHANGELOG.md。支持 breaking change 识别，输出直接可用。
changelog（作者 BytesAgain，v2.0.0）：更像一个通用命令行工具包，不只是生成 changelog，还带检查、验证、格式化、lint、统计、导出（json/csv/txt）等十几个子命令。适合需要灵活操控 changelog 数据的场景。
两个 skill 定位不同：前者专注「从 git 自动生成」，后者专注「changelog 文件全生命周期管理」。
Conventional Commits：自动化的前提
changelog-release-manager 的核心假设是：你的 commit 信息遵循 Conventional Commits 规范。
格式很简单：
type(scope): description
常用 type：feat（新功能）、fix（修复）、docs（文档）、refactor（重构）、perf（性能）、test（测试）、chore（杂项）。
有 breaking change 时，在 commit footer 里加一行：
BREAKING CHANGE: 描述破坏性变更
只要团队遵守这个规范，changelog-release-manager 就能 100% 自动生成准确的 CHANGELOG，不需要人工干预。
不遵守呢？那这个 skill 也救不了你，先统一团队的 commit 规范吧。
changelog skill（v2.0.0）的完整能力
BytesAgain 开发的这个 changelog skill，不是简单的生成器，是一套 changelog 全生命周期管理工具。
子命令一览：
check / validate — 检查 changelog 格式是否合法
generate / format — 生成或格式化输出
lint — 按 Keep a Changelog 规范校验
explain — 把技术化变更描述翻译成用户语言
convert — 格式转换（markdown ↔ 其他格式）
template — 应用自定义模板
diff — 对比两个版本的差异
preview — 预览渲染效果
fix — 自动修复常见格式问题
stats / report — 统计变更分布、生成报告
export — 导出 json / csv / txt
数据存在 ~/.local/share/changelog/，脚本在 scripts/script.sh，纯 bash 实现，不依赖 Node.js。
OpenClaw 生态里还有哪些 changelog 相关 skill
搜了一下 skillhub，changelog 相关 skill 有十几个，我挑几个有代表性的：
changelog-generator（v2.1.1）：最基础的自动生成器，适合快速上手。
changelog-generator-cn（v1.0.0）：中文版，把技术提交翻译成用户友好的发布说明，适合中文项目。
changelog-curator（v1.0.0）：不只是生成，还帮你整理——区分「用户价值」和「内部改动」，输出对外发布的版本。
changelog-linter（v1.0.1）：专门校验 CHANGELOG.md 是否符合 Keep a Changelog 格式，检查版本顺序、日期格式、章节类型、链接引用等。
changelog-watcher（v1.0.0）：监控 GitHub 仓库和 npm 包的新版本，自动摘要 changelog 并标注 breaking change。
十几个 skill，覆盖从生成、校验、整理、监控到导出的完整链路。
落地时的现实问题
说了这么多能力，落地时有几个坑必须提：
第一，Conventional Commits 需要团队共识。skill 再强，有人写 fix 有人写 bugfix 有人写「修复了一个 bug」，工具解析就炸了。解决：用 commitlint 强制校验，不合规范直接拒绝提交。
第二，breaking change 经常被漏标。Conventional Commits 规定要在 footer 写 BREAKING CHANGE，但很多人忘了。结果 CHANGELOG 里没有提示，用户升级直接翻车。解决：code review 重点检查，或让 AI Agent 自动识别并补标注。
第三，生成的 CHANGELOG 需要人工过一遍。自动化能解决 80%，剩下 20% 是判断：这个改动对用户到底意味着什么？要不要加一句迁移指引？这部分目前还得人来做。
总结
changelog 这件事，小到不值一提，大到影响用户信任和版本采用率。
OpenClaw 生态里有一整个 changelog skill 家族：changelog-release-manager 负责从 git 自动生成，changelog（v2.0.0）负责全生命周期管理，changelog-linter 负责格式校验，changelog-watcher 负责监控依赖更新……
前提是团队先统一 commit 规范。Conventional Commits 不难，难的是坚持。
规范有了，skill 装上，发版前最后一步从「对着 Git log 发呆」变成「一条命令，去喝杯咖啡」。
你的时间应该花在写代码上，不是发版前赶 CHANGELOG。