用 Conventional Commits 从 git…

当需要根据 git 提交历史生成发布说明或 changelog 时，解析符合 Conventional Commits 规范的提交并按类型分类输出 markdown。

适用场景

解决思路

1. 先询问用户需要哪种输出：Release Notes（写入 RELEASE_NOTES.md 的单次发布摘要）、Changelog（追加到已有 CHANGELOG.md 或新建）、或两者都要。
2. 确定提交范围：默认使用最近 tag 到 HEAD（即 `<tag>..HEAD`），可先运行 `git describe --tags --abbrev=0` 显示最新 tag 与用户确认；也接受用户自定义范围如 `v1.0.0..v2.0.0` 或 `v1.0.0..HEAD`，作为第一个参数传给解析脚本；若无 tag，则询问范围或默认全部提交。
3. 运行解析脚本提取结构化提交数据：`bash ${CLAUDE_PLUGIN_ROOT}/skills/generate-release-notes/scripts/parse-commits.sh [<range>]`，输出每个提交的字段：COMMIT、TYPE、SCOPE、BREAKING、DESCRIPTION、BODY、FOOTERS。
4. 按类型分组到对应章节：feat→Features、fix→Bug Fixes、perf→Performance Improvements、refactor→Code Refactoring、docs→Documentation、style→Styles、test→Tests、build→Build System、ci→Continuous Integration、chore→Chores、revert→Reverts。
5. 章节按上述顺序排列；每个章节内按 scope 字母顺序排列条目，无 scope 的条目放在最后。
6. 把所有 BREAKING:yes 的提交集中到顶部的 "BREAKING CHANGES" 章节，不论其类型；这些提交同时仍出现在其正常类型章节中。
7. 当多个提交共享同一 scope 时，将它们归组在一个加粗的 scope 标签下。
8. 把 type 为 "other" 的提交（不符合 conventional commit 格式）收集到底部的 "Other Changes" 章节。
9. 确定版本号：若用户提供则使用；否则按 SemVer 规则建议——有 BREAKING:yes 提交则建议 MAJOR 升级，有 feat 提交则建议 MINOR 升级，仅有 fix/docs/style 等则建议 PATCH 升级；读取最新 tag 得到当前版本并计算下一版本，展示建议让用户确认或覆盖。
10. 写入输出：Release Notes 写入 RELEASE_NOTES.md（覆盖旧内容）；Changelog 将新版本条目前置插入 CHANGELOG.md，若文件不存在则带标题创建，保留下方所有已有条目；具体模板参考 references/formats.md。
11. 写完后展示摘要：使用的版本号、处理的提交数、按类别分解（如 "3 features, 2 bug fixes, 1 breaking change"）、写入的文件。
12. 处理边界情况：未找到 conventional commits 时警告用户并提供列出原始提交信息的选项；混合提交时正常处理 conventional 提交、非 conventional 归入 "Other Changes"；范围为空时告知用户并建议检查范围；monorepo 中 scope 对应包/模块时，可提供按 scope 作为顶层章节而非按类型分组。
13. 参考 references/formats.md 获取发布说明和 changelog 的完整输出模板及各章节类型示例。
14. 使用 scripts/parse-commits.sh 解析 git log 为结构化提交数据，它接受可选范围参数，处理 conventional commit 解析、scope 提取、破坏性变更检测和 footer 解析。

适用边界 · 注意事项

• 提交历史不符合 Conventional Commits 规范时，分类效果差，只能归入 Other Changes 或列出原始信息。
• 没有 git tag 且用户无法提供明确范围时，需退化为全部提交，可能包含大量无关历史。