最小化 Git 提交
目标
为当前代理任务创建一个或多个原子提交。每条生成的提交消息遵循 Conventional Commits 规范。对于常规提交，保持低上下文；仅在明确要求完整模式时才进行完整的差异分析。
模式选择
- 默认使用快速模式。
- 仅在用户说
full、要求扫描或分析完整差异、或明确要求检查每一项变更时，才使用完整模式。 - 不要将快速模式静默升级为完整模式。如果快速模式信息不足，请询问变更摘要或请用户选择完整模式。
快速模式
首先使用代理对当前任务的明确摘要。必要时，仅检查：
git status --short
git diff --stat
不要读取完整差异或历史记录。不要猜测摘要中未提及的变更。将所述的变更分组为原子提交，并生成它们的消息。如果用户明确要求提交，请在修改索引或创建提交之前，在文件边界不明确时显示计划中的文件/消息。
完整模式
读取工作区和暂存区的完整相关差异，检查所有变更的文件，并阅读 Conventional Commits 参考文档。检查遗漏的功能、测试、文档、配置、无关文件、敏感文件、生成文件以及独立的逻辑变更。确认生成文件是否应纳入版本控制：保留项目必需的输出（如 lockfiles 或迁移文件），排除构建产物和本地输出。将独立的功能、缺陷修复、重构和仅格式化的变更拆分为原子提交；当变更紧密耦合且无法独立测试或回滚时，保持它们在一起。使用现有项目命令运行与变更文件相关的检查。默认不运行完整的测试、lint 和类型检查套件；重用任务期间已运行的检查，仅在请求或变更需要时扩展验证。除非明确要求，否则不检查历史记录。
在 git add 或 git commit 之前，保留当前任务之外的用户变更。仅在用户明确要求提交时才执行这些变更。切勿在此技能中执行推送操作。
提交规则
使用以下格式：
<类型>[可选作用域]: <描述>
[可选正文]
[可选脚注]
- 使用
feat表示新功能，使用fix表示缺陷修复。 - 当项目的
docs、style、refactor、perf、test、build、ci、chore和revert类型能准确描述变更时，优先使用它们。 - 仅在有必要上下文时，才在括号中使用名词性作用域。
- 使用
!标记在冒号之前，或使用大写的BREAKING CHANGE:脚注来标识重大变更。 - 描述保持简洁、现在时、祈使句，最好在 72 个字符以内。
- 一个提交代表一个逻辑变更。尽可能将独立的功能、修复、测试、文档和重构变更拆分开来。
fix对应 SemVer PATCH，feat对应 MINOR，任何重大变更对应 MAJOR；除非另有要求，否则不要修改版本文件。
安全和确认
- 默认不使用
git add .；仅添加属于当前任务的文件。 - 绝不提交
.env、凭据、令牌、私钥或其他秘密信息。 - 在完整模式下，审查暂存内容是否包含秘密信息，并确认生成或构建文件是项目所期望的，然后再包含它们。
- 除非用户明确要求该确切操作，否则绝不修改 Git 配置、跳过钩子、强制推送或修改现有提交。
- 不要将用户预先存在的更改与代理的更改混在一起。
- 当任务边界、文件所属、逻辑拆分或敏感文件状态不明确时，停止并询问。
- 创建消息并不等同于允许创建提交；在
git add或git commit之前，需要明确的提交请求。
参考
在完整模式下，或当类型、脚注、重大变更、回滚、SemVer 或 FAQ 问题需要详细处理时，请阅读 references/conventional-commits.md。