技能介绍

变更日志为什么总做不好

很多团队的版本发布流程卡在最后一步：代码合并完，CHANGELOG 却没人写、没人校。结果出现几种典型问题：提交信息随性，feat:、fix、mixed with Chinese description 混用，无法从提交历史自动提炼版本内容；发布说明靠人手拼，格式每次不同，阅读者很难扫读；版本号凭感觉升，破坏性变更直到发布后才被发现。这套技能把「提交 → 校验 → 生成变更日志 → 产出发布说明」串成可重复的流程，减少人工粘贴和格式漂移。

技能如何工作

核心思路是先把约定定死，再让工具按约定跑。技能会引导你落地以下能力：

Conventional Commits：规范 type(scope): description 的提交格式，例如 feat(auth): add token refresh，为自动化提供结构化输入。
提交校验：在提交或 CI 阶段用 commitlint 拦截不符合约定的 message，避免脏提交进入历史。
Keep a Changelog 格式：按 Added、Changed、Deprecated、Removed、Fixed、Security 分组组织内容，保持结构稳定。
语义化版本管理：根据提交类型自动建议 major.minor.patch 升级策略，遇到 BREAKING CHANGE 或 ! 后缀时明确标记破坏性变更。
发布说明生成：复用同一份变更日志产出 GitHub/GitLab release notes，避免两套内容维护。

技能同时给出 Do / Don't 清单：一个 commit 只做一件事、关联 issue 编号、scope 团队统一；不要手改自动生成的日志、不要跳过 CI 校验、不要忘记标注破坏性变更。

适用边界

生成的变更日志默认只做展示与写入仓库的预览，不会自动安装依赖、修改系统权限、创建持久化定时任务或执行下载动作。涉及发布、删除、部署等外部写入操作时，技能会先展示目标与影响，等你明确确认后再执行。仓库凭据只用于对应官方服务，不回显、不记录、也不转发到无关地址。命令与代码片段默认作为参考，只有在你明确要求且目标范围清楚时才会运行。