Git 提交

以实际变更为依据，产出可独立理解、可回退的原子提交（atomic commit）。按请求选择写信息、检查信息或执行提交；自动调用本技能本身不代表获得提交授权。

1. 确定规范与范围

• 优先采用用户指定规则和仓库的 AGENTS.md、CONTRIBUTING、提交模板及 commitlint 配置；没有约定时使用下方默认格式。
• 编写信息前先确定项目主要自然语言（例如中文或英文）：用户明确指定的提交语言优先，其次是仓库明确约定；否则查看近期人工提交（可从 git log -20 --format=%s 开始），结合主 README、贡献文档及维护者注释推断。排除机器人提交、生成内容和翻译副本的干扰，不以代码标识符、机器时区或用户所在地判断项目语言。证据混杂时优先延续近期人工提交的主流语言；仍无依据时采用用户当前交流语言，并简短说明这一假设。
• 仅咨询格式或提供了充分的变更描述时，直接据此回答，不要求 Git 工作区。根据描述生成的草稿应说明依据，不能声称已验证代码。
• 对当前仓库生成或执行提交时，读取 git status --short、git diff --cached、git diff；逐个检查范围内未跟踪文件。用户指定“已暂存”时，以 index 内容为提交事实，即使同一文件还有未暂存修改。
• 按下面的分组规则确定每项逻辑修改的归属，再选择 type；文件、工单和 type 都不是提交边界。

分组规则

• 同一交付默认合并：先用一句话确定本轮主要交付目标，再归入相关的小功能、小修复及配套改动；新功能和已有功能的一轮完善都适用。以共同的验收目标或交互链路判断关联性，即使小改动并非主功能运行所必需，也可随同交付。同一根因是合并线索，不同根因或技术上可单独撤销不构成拆分理由。
• 拆分须有独立价值：存在明确的独立验收、发布或回退价值时才拆分，并能简短说明具体收益。例如同一页面的展示调整与可分别验收、发布的权限需求应分开；无关旧缺陷、独立升级和顺手清理按各自目的分组。同一页面、目录或本次会话本身不代表同一交付。
• 配套改动随目标归属：相关重构、依赖、测试和使用说明随所属交付；具有独立交付价值的公共前置改动可先提交。按合并后的主要意图选择 type：新功能及开发中的相关修复通常为 feat，修正已有错误行为为 fix。本轮修改形成新提交；仅在明确授权整理未共享历史时考虑合回已有提交。
• 提交按依赖排序：每一步都应形成可构建、可验证的完整状态。共享改动有独立意义时先提交；否则放入首先需要它的功能提交，后续提交依赖前者。

按上述规则确认需要拆分，或执行部分暂存、隔离验证时，读取 拆分与验证。先确定交付边界，再选择 hunk 和构造中间状态。

完成标准：规范、证据来源和操作模式已确定；范围内每项逻辑修改恰有一个归属，拆分有明确的独立价值，提交顺序满足依赖。拆分明确且已有提交授权时直接执行、完成后汇报；只有归属或范围存在实质歧义时，先展示推荐方案（目的、逻辑修改、依赖和验证方式），等待用户确认后再执行相关提交。技术上难拆时先按参考处理，不据此反复索要确认。

2. 编写或检查信息

默认只写一行标题，scope 和 ! 按实际需要选用：

<type>(<scope>)!: <subject>

这些扩展类型是默认团队约定，Conventional Commits 并未强制一份完整类型枚举。

• scope 取稳定的模块或领域名；跨模块且没有合适范围时省略。subject 先写具体的主要变化，再按需用短语补充相关小改动；只保留有助于理解交付的重要变化，不逐项复述 diff。简单改动只写主要变化即可。
• 标题中的自然语言按该语言的习惯衔接：中文可用逗号分隔主次、顿号连接同类事项；英文可用分号或连词，其他语言采用相应标点。协议前缀仍使用 ASCII 冒号和空格（: ）。示例是表达方式，不是固定句式：
  • 中文：fix(check-record-ledger): 完善检查详情展示，修复固定列遮挡、翻页滚动异常
  • 英文：fix(check-record-ledger): improve detail layout; fix column overlap and pagination scrolling
• subject、body 和 footer 的自然语言说明使用第 1 步确定的语言；feat、fix、BREAKING CHANGE 等协议词、既有 scope、代码标识符和专有名词保留原文。版本提交中的示例描述也按此规则调整。标题长度服从仓库规则，无规定时保持简洁，不把固定字符数当成规范硬要求。
• 多行仅用于必要的补充说明或仓库要求：标题不足以表达的原因、行为影响或迁移方法放入 body，结构化信息放入 footer，各部分以空行分隔。标题已说明清楚时省略正文；不为重复标题或罗列小改动追加多行。Issue 引用须真实且与任务有关；无法确认关闭意图时使用关联说明，不虚构 Closes。
• 判断兼容性，而非改动行数。存在破坏性变更时使用 ! 或 BREAKING CHANGE:；推荐在 footer 写明受影响契约及迁移方式。refactor、chore 等类型同样可能含破坏性变更。
• 检查已有信息时分别判断语法与语义：格式合法仍可能类型错误、遗漏破坏性影响或与 diff 不符。指出具体偏差并给出修订稿。

完成标准：每组变更都有与证据一致的信息，描述语言与项目证据或明确指定一致，兼容性影响已评估，仓库格式约束已应用。仅请求信息或检查时在此交付，不进入执行分支。

3. 按授权执行并核对

用户明确要求“提交这些改动”等即授权对应范围的普通提交；已有授权继续有效。“写提交信息”“看看怎么提交”只产出草稿。amend、历史重写、tag、push 和发布分别按用户实际授权执行，不能从普通 commit 请求推导。

涉及版本文件、npm version 或已有版本提交时，先读取 版本提交。

执行普通提交时：

1. 检查现有 index 是否包含范围外内容；只暂存目标文件或 hunks。若混入他人已暂存内容，先明确处理方案，保留其暂存状态和工作区修改。不要以 git add . 或 git commit -a 代替范围选择。
2. 复核最终 git diff --cached 和 git diff --cached --check；空 diff 时报告无可提交内容。运行仓库要求且与变更相关的检查，验证对象是“此前提交＋本次 index”。工作区含其他修改时，按 拆分与验证 隔离检查；已有检查仅在对应相同内容与环境时复用。
3. 用 git commit -F <message-file> 提交审阅后的信息；消息文件放在仓库外的临时目录，保留真实换行并使用 UTF-8。按当前 shell 正确传递参数，不把消息正文拼成可执行命令。
4. hook 失败时检查原因及其修改，修复范围内问题后重新审阅；禁止为通过提交擅自使用 --no-verify。命令失败或结果不确定时先检查 HEAD、index 和工作区，确认是否已经生成提交，再决定下一步。
5. 用 git log -1 --format=fuller、git show --stat --oneline HEAD 和 git status --short 核对结果。拆分多次提交时逐次重复核对，避免重复提交或遗漏变更。

完成标准：报告实际提交的哈希、信息和检查结果，以及仍未提交的相关内容；未执行时明确交付的是草稿。执行被阻止时说明具体原因，不报告成功。

规范依据

按需追溯设计来源和规范边界时，读取 来源记录。