commit

此技能会更改 Git 历史，必须明确执行。

不可妥协的规则：

1. 起草提交说明或暂存文件前，先阅读实际差异。
2. 如发现机密信息、冲突标记或明显非预期文件，必须停止。
3. 按文件名明确暂存文件。绝不使用 git add -A 或 git add .。
4. 提交前，针对已更改的部分运行最相关的检查。
5. 提交操作必须由用户明确发起。如果拆分策略或文件范围不明确，先询问。

提交

输入

• $request：可选的提交指导，例如意图、范围提示或首选的提交说明措辞

目标

创建干净、经过审慎确认的提交，并确保：

• Conventional Commit 格式的主题准确
• 明确遵守暂存纪律
• 扫描阻断项
• 进行相关验证
• 最终报告包含哈希、提交说明和剩余工作区状态

步骤 0：确认用户明确要求提交

此技能仅供用户主动请求时使用。

只有在用户明确要求提交时才使用。如果用户只是想进行审查、规划或创建 PR，则转到相应工作流。

如果工作区似乎包含无关更改，且拆分方式不明确，则在修改 Git 历史前使用 AskUserQuestion。

成功标准：已明确要求执行提交操作，且预期提交范围清楚。

步骤 1：收集实际 Git 上下文

暂存任何内容前，检查实际状态：

• git status --short
• git diff HEAD
• git branch --show-current
• git log --oneline -15
• git status -sb

规则：

• 阅读完整差异，而不只是 --stat
• 如果某个差异部分不清楚，使用 Read 查看具体更改文件
• 判断这些更改应合并为一次提交，还是拆分为多个互不相关的提交

成功标准：了解更改内容、更改位置，以及是否可以合并为一次提交。

步骤 2：扫描阻断项和非预期文件

检查已更改文件中的以下内容：

• 机密信息或凭据文件
• .env 或同类本地机密文件
• 冲突标记
• 明显的意外产物
• 调试残留
• 异常大的文件或二进制文件

阻断规则：

• 冲突标记：停止
• 机密信息或私人凭据文件：停止并排除
• 文件是否应纳入提交存在歧义：暂存前先询问

警告：

• 调试产物可能是用户有意保留的；应发出警告，不要擅自删除

必要时，加载 references/commit-conventions.md，了解阻断项清单和扫描顺序。

成功标准：不会将任何阻断项纳入即将创建的提交。

步骤 3：运行最相关的检查

仅运行与已更改部分和项目现有工具相匹配的检查。

例如：

• TypeScript：类型检查、lint、格式检查
• Rust：适用时运行针对性的 cargo test 或 cargo clippy
• Go：针对性的 go test
• Python：运行仓库中已有的针对性测试或 lint 命令

规则：

• 优先针对已更改部分进行验证；除非仓库只提供全量检查，否则不要盲目执行全仓库检查
• 如果即将提交的文件未通过检查，则停止并解决问题，或征求用户明确指示
• 如果格式化或自动修复工具改写了文件，则在暂存前重新评估更改范围

成功标准：已更改部分通过相关的提交前检查；或者用户已明确批准在存在非阻断问题的情况下继续。

第 4 步：拟定提交格式

确定：

• 提交类型
• 作用域
• 主题行
• 是否需要正文
• 是否应将工作拆分为多个提交

指南：

• 使用差异、分支名称和近期提交中的用词来推断作用域
• 如果更改涉及多个互不相关的区域，则省略作用域
• 仅当主题行信息不足时才添加正文
• 如果需要多个逻辑提交，请按文件组拆分，并有意安排提交顺序

加载 references/commit-conventions.md，了解：

• 提交类型的判断依据
• 作用域检测规则
• 正文示例

如果拆分策略存在歧义，请使用 AskUserQuestion。

成功标准：提交消息格式符合实际更改，且暂存计划明确。

第 5 步：明确暂存并创建提交

仅按名称暂存预期文件。

规则：

• 绝不使用 git add -A
• 绝不使用 git add .
• 不要包含密钥、生成的杂项或无关修改
• 除非用户明确要求，否则不要使用 --amend
• 不要使用 --no-verify
• 不要使用 --allow-empty

创建提交时：

• 使用规范的 Conventional Commit 主题
• 仅在需要时添加可选正文
• 除非用户明确要求，否则不要添加共同作者署名行

如果需要多个提交，请依次执行，并在创建下一个提交前验证当前提交。

成功标准：预期文件已提交，且没有暂存任何非预期文件。

第 6 步：验证并报告

提交后，检查：

• git log --oneline -1
• git status --short
• git status -sb

报告：

• 提交哈希
• 提交消息
• 分支是否领先于远程分支
• 是否还有未提交文件
• 是否创建了多个提交

如果工作树仍有未暂存或未提交的更改，请明确说明，不要暗示仓库是干净的。

成功标准：用户能够准确了解提交内容，以及分支的当前状态。

防护措施

• 不要主动创建提交。
• 不要让模型通过 SkillTool 调用此技能；此工作流仅供用户使用。
• 不要添加 paths:。这是一个通用工作流技能。
• 不要添加 context: fork。提交状态必须保留在活动工作区中。
• 不要在 SKILL.md 中保留冗长的检查清单、评分表或失败案例目录。
• 如果用户意图不明确，不要悄悄拆分或排除文件。

何时加载参考资料

• references/commit-conventions.md 用于了解提交类型映射、作用域检测、阻碍项扫描顺序，以及消息和正文的判断依据。

输出约定

报告：

1. 创建了一个提交还是多个提交
2. 每个提交的哈希和最终消息
3. 运行的检查
4. 受阻或排除的文件
5. 剩余的工作树或分支状态