用途
git-commit 用于把当前工作区中的改动整理成一个或多个原子提交，并自动撰写提交信息。当用户运行 /git-commit 或要求提交工作时触发。用户调用该命令意味着信任执行者自行判断如何分组和撰写信息，因此该技能不会停下来请求批准，而是在完成后报告所做的工作。
用户传入的任何参数都是上下文而非命令：它是对意图的提示（例如“处理评审反馈”“这个有风险，注意迁移”），用于影响分组方式和信息内容，而不会直接作为提交信息。
主要能力
- 查看工作区全部改动：运行 git status、git diff、git diff --staged 以及 git log --oneline -15，了解哪些文件被修改、新增、删除或未跟踪，并参考近期历史以匹配语气、发现关联的 issue 或 PR。
- 阅读 diff 以理解改动的“为什么”，而不仅是“是什么”。
- 判断提交分组：目标是原子提交，每个提交是一个完整、连贯、可独立成立的变更。
- 精确暂存：对整文件分组使用 git add <paths>；对同一文件中属于不同逻辑分组的改动，只暂存相关 hunk，通过生成补丁并用 git apply --cached <patch> 应用，因为交互式 git add -p 不可用。提交前用 git diff --staged 验证。
- 撰写提交信息：主题行使用祈使语气、首字母大写、不加结尾句号，代码标识符用反引号包裹，尽量控制在约 50 字符内；仅在携带真实信息时添加语义前缀（如“Breaking change:”）；不手动追加 (#123) 形式的 PR 编号。正文在主题行后空一行，按约 72 字符换行，解释“为什么”而非“是什么”，保持简洁，指出意外之处或尝试过的替代方案，标注风险与依赖，面向非技术读者使用平实语言。仅在明显适用时引用 issue 或 PR，绝不编造或猜测编号，使用引用式 markdown 链接。
- 每个提交末尾附加 Claude 共同作者署名，格式为单独一行、前面空一行：Co-Authored-By: Claude noreply@anthropic.com。应使用当前会话实际运行的模型名称，而非照抄示例中的固定版本。
使用方式
- 理解改动：并行运行 git status、git diff、git diff --staged、git log --oneline -15。若确实不清楚，可以问一个聚焦的问题；通常 diff 加近期历史已能说明情况。若没有可提交内容，说明并停止，绝不创建空提交。
- 决定分组：这是需要判断的环节。当改动讲述同一个故事时倾向单个提交（例如新功能包含模型、迁移、控制器、视图、测试，属于一个逻辑变更，拆开会产生单独无法运行、无法回滚的提交）。当改动确实彼此独立时拆分为多个提交，例如处理多个不同的评审意见（每条意见一个提交）、若干互不相关的重构或清理、与功能工作同时进行的缺陷修复、依赖升级加上需要它的功能。判断标准：如果回滚其中一部分，其余部分是否仍然成立？是则分开，否则合并。拿不准时，宁可少而大，不要多而碎。
- 逐个分组精确暂存并提交。尊重 pre-commit 钩子：若钩子修改文件或失败，不要对抗，如实呈现；除非用户要求，不使用 --no-verify。不推送，不 amend 或重写已有提交，该命令的职责止于从未提交的工作创建新提交。
- 撰写信息，遵循上述主题行与正文规范，并附加 Claude 署名。
- 报告结果：提交后向用户展示结果，通常 git log --oneline 列出新提交即可，让用户看到分组与措辞方式；若做了值得说明的判断（如“我把缺陷修复从功能中拆了出来”），用一句话说明。
适用场景
- 用户运行 /git-commit 或要求提交当前工作。
- 工作区中同时存在多个彼此独立的改动，需要拆分为原子提交。
- 需要按团队规范撰写提交信息，包括主题行格式、正文说明原因、风险标注和共同作者署名。
限制
- 不推送、不 amend、不重写已有提交。
- 不盲目使用 git add . 或 git add -A。
- 不使用 --no-verify，除非用户明确要求。
- 不创建空提交。
- 不编造或猜测 issue/PR 编号。
- 交互式 git add -p 不可用，需改用补丁方式暂存部分 hunk。
- 关于收费、价格、平台支持等信息，资料中暂未提供。