SKILL.md
只读
名称
commit-work
描述
创建高质量的 Git 提交：审查/暂存预期更改，拆分为逻辑提交，并编写清晰的提交消息（包括 Conventional Commits）。当用户要求提交、编写提交消息、暂存更改或将工作拆分为多个提交时使用。
提交工作
目标
创建易于审查且安全发布的提交：
- 仅包含预期更改
- 提交在逻辑上范围明确（必要时拆分）
- 提交消息描述更改内容和原因
需要询问的输入（如果缺失）
- 单个提交还是多个提交？（如果不确定：当存在不相关的更改时，默认使用多个小提交。）
- 提交风格：必须使用 Conventional Commits。
- 任何规则：最大主题长度、必需的作用域。
工作流程（检查清单）
- 在暂存前检查工作树
git statusgit diff（未暂存）- 如果更改很多：
git diff --stat
- 决定提交边界（如果需要则拆分）
- 按以下方式拆分：功能 vs 重构、后端 vs 前端、格式化 vs 逻辑、测试 vs 生产代码、依赖更新 vs 行为变更。
- 如果更改在同一个文件中混合，计划使用补丁暂存。
- 仅暂存属于下一个提交的内容
- 对于混合更改，优先使用补丁暂存：
git add -p - 取消暂存一个块/文件：
git restore --staged -p或git restore --staged <path>
- 对于混合更改，优先使用补丁暂存：
- 审查实际将要提交的内容
git diff --cached- 合理性检查：
- 无秘密或令牌
- 无意外的调试日志
- 无无关的格式变动
- 用 1-2 句话描述暂存的更改（在编写消息之前）
- "更改了什么？" + "为什么？"
- 如果无法清晰描述，则提交可能太大或混合了更改；返回步骤 2。
- 编写提交消息
- 使用 Conventional Commits（必需）：
type(scope): short summary- 空行
- 正文（什么/为什么，而非实现日记）
- 页脚（BREAKING CHANGE）如果需要
- 对于多行消息，优先使用编辑器：
git commit -v - 如有帮助，使用
references/commit-message-template.md。
- 使用 Conventional Commits（必需）：
- 运行最小的相关验证
- 在继续之前，运行仓库中最快的有意义检查（单元测试、lint 或构建）。
- 重复下一个提交，直到工作树干净
交付物
提供：
- 最终的提交消息
- 每个提交的简短摘要（什么/为什么）
- 用于暂存/审查的命令（至少：
git diff --cached，以及任何运行的测试）
