Git 规范提交生成器

问题在哪

日常提交里常见 update code、fix bug 这类说明：队友扫 git log 看不出改了什么，bisect 和自动生成 changelog 也几乎没法用。自己写 Conventional Commits 还要对照 diff 猜 type、想 scope，再补一句中文，往往要花几分钟，且疲劳时格式前后不一致。

技能如何工作

技能要求先读真实 diff，而不是凭文件名猜意图。优先用捆绑的扫描脚本产出结构化 JSON：staged_files / unstaged_files、diff_stats、新建/删除/重命名文件列表以及当前分支名，用来判断变更的「形状」——例如单文件几行多半是 fix，新目录下多文件大量新增更可能是 feat。

随后按主导意图选定单一 type（feat、fix、docs、refactor、perf、test、chore、ci、build、revert 等），并从路径推导可选 scope（单文件用 basename、单目录用目录名、跨模块可省略）。正文遵循规范：英文用祈使语气、首行 72 字符内；中文一行自然表述、与英文意图对齐。若有破坏性变更写 BREAKING CHANGE: footer；需要时加简短 body 或 Closes #123。最后以代码块给出可粘贴的双语 message，并在你确认后再执行 git commit；无暂存时会先问是否 git add。

边界与注意

• 一次提交只表达一个目的；diff 里混了三件不相干的事，应建议拆 commit，而不是塞进模糊的 chore。
• diff 没写清的「为什么」不要编造，只描述做了什么。
• 不做 git reset、git stash 等破坏性操作；未确认前不会擅自 git add -A。