技能介绍

要解决什么问题

团队里常见两种提交信息：要么是一句「fix bug」，要么是粘贴整段 diff 摘要。前者对 semantic-release、changelog 生成器和按类型过滤的 CI 毫无用处；后者又让人类 reviewer 抓不到重点。Conventional Commits 把类型、范围、主题和可选正文/footer 固定成可解析格式，但日常写 diff 时仍容易选错 type、主题超长、或把多个无关改动塞进一条 commit。

技能如何工作

本技能把 Conventional Commits 当成默认契约：先通过 git diff --cached --stat 与完整 staged diff 看清改了哪些文件，必要时用 git log --oneline -5 对齐近期风格，再按固定流程归类变更。

核心能力包括：

类型与范围：在 feat / fix / refactor / docs 等类型表中选型，并用 feat(auth) 这类 scope 标出影响面
主题约束：祈使语气、句末无句号、类型后小写，主题尽量压在 50 字符内（硬上限 72）
正文与 footer：非显而易见改动写 Why 与行为差异；破坏性变更用 ! 或 BREAKING CHANGE:；可附 Closes #123 等
多改动 diff：无关变更建议拆 commit；主题相关则取主导 type，scope 宁窄勿宽

用户说「写 commit message」时，技能会先查 git status 与暂存区 diff，给出完整提案，并在真正 git commit 前与你确认；仅在用户同意时才考虑 git commit --amend。

适用边界

Merge commit 默认保留 Merge branch '...' 格式，除非你明确要求改写。Revert 用 revert: 并在主题里带上原 commit hash。Squash 时取被压扁提交里最重要的一类 type（例如同时有 feat 与 fix 时偏 feat）。WIP 类提交只在用户明确要求时用 WIP: 或 chore: wip。