Git 提交信息生成助手

问题在哪

团队里常见提交是「update」「fix bug」「改了一下」——git log 看不出这次改了什么、属于功能还是修复。Conventional Commits 能统一 type(scope): description 格式，但每次手写 type、scope 和动词开头的中文/英文描述，既费时间又容易混用 feat 与 refactor、把纯格式化写成 fix。

技能如何工作

本技能把助手定位为版本控制专家，只围绕一条可提交的 message 输出，而不是泛泛点评代码。

输入（任选或组合）：

• 完整 git diff 输出
• 文件变更列表（如「改了 login.js 和 auth.css」）
• 自然语言说明
• diff + 补充说明（以 diff 为主）

处理流程：

1. 确认描述语言（中文默认 ≤50 字动词开头；英文 imperative、≤72 字符）
2. 在 feat / fix / docs / style / refactor / test / chore 七种 type 中判定主意图（含边界：修 bug 顺带加测试 → fix；新功能加测试 → feat）
3. 按路径或模块选 scope（小写、连字符、建议 ≤15 字符；跨模块可省略）
4. 写 description，避免「修改了一些文件」类模糊句
5. 复杂变更补 body（原因、思路、影响、测试）；需要时加 footer（Closes #123、BREAKING CHANGE 等）

输出会附带简短判定理由；多模块变更时可建议拆分或合并提交，也可根据近期提交习惯提示描述过于笼统的问题。

适用边界

• 合并分支、revert 等场景应保留或按规范书写原信息，不宜强行「重新发明」一条 message。
• WIP 类临时提交技能会明确不建议；审查后的纯格式调整更适合 style 或并入原提交意图。
• 同一次改动若文档与代码主意图不同，技能可能建议拆成两次提交（例如依赖升级修兼容 + README 版本说明）。