commit

提交

使用此技能，可将请求的更改整理为一个或多个整洁的提交，同时避免纳入无关工作。

范围

• **默认：**仅提交当前任务中由当前 Agent 所做的更改。根据已知的初始状态、对话和工具历史判断归属；不要仅凭当前差异或文件路径推断。
• **所有更改：**仅当用户明确要求提交所有更改、全部内容或整个工作树时，才检查并提交整个工作树。
• **明确指定的子集：**遵照用户指定的文件、代码块、提交或排除项。
• **临时产物：**除非用户明确要求，否则排除仅用于调查的诊断信息、日志、跟踪记录、性能分析输出、实验性开关、屏幕截图和复现用例。保留永久性回归测试；如有疑问，请询问。
• 如果无法可靠确定更改归属或请求的范围，请在暂存前停止并询问。切勿凭猜测纳入已有的、并发产生的或用户编写的更改。

审批模式

• **直接模式：**如果用户要求提交，则分析请求范围并创建所需的一个或多个提交，无需另行征求同意。
• **计划模式：**如果用户要求提供计划、先审查提交、等待、提交前提示或询问，或以其他方式要求先审批，则先提供提交计划，并等待用户明确批准（例如回复 go）。获批后，创建所有已商定的提交；除非工作树发生意外变化，否则无需再次询问。
• **澄清后停止：**无论处于哪种模式，如果更改归属不明确、混合代码块无法安全暂存、仓库指南与用户请求冲突，或预期分组存在足以导致提交有误的歧义，则在提交前停止。
• **审批回复：**如果上一轮已提供提交计划，而用户现在回复 go，则将其视为对该计划的批准。暂存前重新检查工作树。

检查

1. 首先阅读仓库指南：AGENTS.md、贡献文档或可见的提交规范。
2. 判断这项工作是否修复了已知的 GitHub 问题。依据只能来自用户明确提供的上下文、已批准的问题或任务文档、经核实的问题 URL，或仓库元数据。不要仅凭偶然出现的编号推断两者有关联。
3. 使用 git status -sb、git diff --stat、git diff --staged --stat，以及针对性的 git diff / git diff --staged 检查状态。暂存前检查相关的未跟踪文件。
4. 将已暂存、未暂存和未跟踪的更改分类为范围内或范围外。任务归属并不意味着这些更改都应纳入；应将任务创建的检测工具和测试夹具归类为永久性或临时性。将整个工作树视为上下文，而非提交授权。
5. 保留范围外的已暂存更改。如果范围内的更改位于完全归属明确的路径中，可仅按路径提交，让索引中的无关条目保持不变；如果范围内外的代码块位于同一路径，或无法确定能否安全隔离，则停止并询问，不要取消暂存或提交他人的工作。
6. 遵守明确的排除要求，例如用户说不要提交的调试日志或生成的产物。保持这些更改未暂存，并在之后报告。
7. 如果没有范围内的更改，说明这一点，并报告剩余的范围外更改，不要提交。

分组

按一个连贯的概念对范围内的更改进行分组：功能、修复、重构、测试、文档、配置、依赖项或子系统。如果更改可以独立审查、撤销或说明，优先拆分为不同提交。

如果某个文件包含无关更改，请使用 git add -p 或其他按路径或代码块限定的暂存方式进行拆分。不要仅因更改位于同一文件，就将无关代码块放入同一提交。

消息风格

如果用户明确提出指示，或仓库或工作区中有相关指南，请遵循这些要求；它们优先于本技能的默认规则。否则，使用以下默认规则：

• Conventional Commit type: subject
• 不使用范围括号
• 使用祈使式、具体的主题
• 末尾不加句号
• 除非用户明确要求，否则不添加 Co-authored-by trailer
• 如果提交修复了已验证的 GitHub issue，在主题末尾追加 #<number>

确认主题前：

• 使用 diff 中可见的术语，说明具体行为和目标，例如函数、API、类型或面向用户的效果。
• 优先使用受影响的符号或类型名称，而不是生造宽泛的概括性说法。确保主题便于在 git log 中搜索。
• 拒绝可能适用于多个无关 diff 的主题。请问自己：“不打开 diff，这个主题能说明发生了什么变化吗？”
• 如果可以明确指出具体改动，避免使用 improve behavior、update handling 或 compare collection values 等含糊的抽象说法。

仅当该提交旨在修复相应 issue 时才使用 issue 后缀，而不仅仅是与其相关或在调查过程中发现了它。对于明确修复的多个 issue，在末尾追加每个经过验证的引用。仓库专属的消息规则或用户明确的指示仍优先适用。

示例：

fix: preserve scroll offset after prepend
fix: preserve failed CRUD creates #547

避免使用带范围的主题（fix(list): ...）和含糊的概述（update stuff）。

如果行为变化的原因、不变量或验证方式无法从标题中明显看出，请在正文中说明。

计划输出

启用计划模式时，展示：

Proposed commits (N):
1. type: concrete subject
   Rationale: Why this group belongs together.
   Files: path/a, path/b

然后请用户回复 go 或提出修改意见。在用户批准前，不要暂存或提交。

在直接模式下，在内部完成规划。只有在有助于用户理解多次提交的拆分时，才在提交前或提交过程中提供简要概述。

提交

对于每个分组：

1. 使用限定路径或限定代码块的方式，仅暂存该分组。不要悄悄取消暂存范围外的更改。
2. 使用 git diff --staged --stat、针对性的 git diff --staged 和 git diff --staged --check，确认预期提交仅包含该分组。如果索引中仍有无关条目，仅对完全由你负责的路径使用限定路径提交，并单独验证这些路径。
3. 使用已商定的消息提交。
4. 钩子运行后重新检查工作树，然后再继续下一个分组；如果预提交钩子运行的检查范围超出仓库文档规定的限定检查，请使用仓库文档中规定的方式限定范围或跳过，并说明原因。

所有提交完成后，报告提交哈希以及任何仍未暂存的文件。如果提交失败，请停止并报告确切的失败信息和当前 Git 状态。