技能介绍

要解决的发布说明问题

发布说明最容易坏在三种地方：提交信息不统一、版本号拍脑袋、破坏性变更没人提醒。手工整理 git log 时，常常把内部改动写成用户语言，又把需要迁移的接口改动漏掉。CI 即使能跑，也只是打出日志，未必生成一份可审计、可直接进入 CHANGELOG.md 的草稿。

核心工作方式

这个技能把发布工程拆成可检查的步骤。它先解析约定式提交，识别 feat、fix、perf、refactor、docs、test、build、ci、chore、security、deprecated、remove 等类型，并通过 type(scope)!: 或正文中的 BREAKING CHANGE: 判定破坏性。随后按 SemVer 推导 major、minor、patch 或 none，给出建议版本号，可支持 alpha、beta、rc 等预发布。

渲染时按 Keep a Changelog 的 Added、Changed、Fixed、Deprecated、Removed、Security 分组，把提交摘要改写成对用户有意义的句子；破坏性变更必须附带迁移动作，安全修复单独归入 Security，空章节省略，跨章节重复条目去重。输出包括结构化 ChangelogEntry 和一段自然语言摘要，说明版本结论、依据、需要人工补的信息以及是否建议发版。写入采用 prepend，不覆盖历史；发版前仍需人工润色，提交格式可用 lint 做门禁，只有标签成功后才打 tag。

适用边界与注意点

它处理提交消息、版本推导和 changelog 渲染，不替团队决定发版时机，也不回答业务是否应该上线。如果范围内没有有效约定式提交，应明确报错，而不是编造空说明。它适合发版标签准备、从 git 历史生成 CHANGELOG.md、CI 自动出草稿、热修与回滚规划；热修分支应从最近稳定 tag 拉出，只包含最小修复，并单独给 patch 条目。回滚阈值应基于错误率、延迟、核心功能、安全事件和数据损坏判断，能降级功能开关时优先降级，而不是急着回代码。