何时使用
当你决定每个提交或PR中应包含什么内容时，加载此技能。
适用于以下场景：
- 将一个功能拆分为可审查的工作单元。
- 在打开PR前准备提交。
- 将大型变更转换为链式或堆叠的PR。
- 保持审查者的认知负荷健康。
- 应用SDD任务，同时避免意外产生超过400行变更的PR。
核心规则
| 规则 | 要求 |
|---|---|
| 按工作单元提交 | 一个提交代表一个可交付的行为、修复、迁移或文档单元。 |
| 不按文件类型提交 | 避免独立提交models、services、tests（如果单个提交无法独立工作）。 |
| 测试与代码一同提交 | 测试应与它们验证的行为放在同一个提交中。 |
| 文档与用户可见变更一同提交 | 文档应与它们解释的功能或工作流程放在一起。 |
| 讲述一个故事 | 审查者应能通过差异和提交信息理解每个提交存在的原因。 |
| 面向未来PR | 当变更变大时，每个提交应成为链式PR的候选。 |
| SDD工作负载保护 | 如果SDD任务预测变更加载超过400行，在实现之前将提交分组为链式PR切片。 |
| 预算不是代码压缩 | 绝不为适应审查预算（默认400行，或会话review_budget_lines）而通过删除注释、空行、文档、测试或压缩代码来缩小差异。应按工作单元切片或报告超量。 |
工作单元检查清单
在提交前，确认：
- 该提交具有单一明确目的。
- 仅应用此提交后，仓库仍然合理。
- 相关单元包含测试或文档（如适用）。
- 回退时不需撤销不相关的工作。
- 提交信息解释了结果，而非文件列表。
拆分示例
| 糟糕的拆分 | 更好的工作单元拆分 |
|---|---|
add models | feat(auth): add token validation domain model and tests |
add services | feat(auth): wire token validation into login flow |
add tests | 测试包含在每个行为提交中 |
update docs | 文档包含在它们解释的用户可见变更中 |
PR关系
将工作单元提交用作链式PR的基础：
- 构建最小的独立工作单元。
- 包含该单元的验证。
- 使用Conventional Commit信息提交。
- 如果PR接近400行变更，将提交或提交分组提升为链式PR。
SDD关系
当sdd-tasks生成审查工作负载预测时：
- 低风险：在一个PR内保留工作单元提交。
- 中风险：按工作单元提交，并在创建PR前监控变更行数。
- 高风险：遵循SDD
delivery_strategy——对于ask-on-risk策略询问，对于auto-chain策略自动切片，对于超出预算的single-pr策略要求size:exception，对于exception-ok策略记录已接受的size:exception。 - 拆分有边界：经过一次诚实的切片后，如果没有任何内聚的工作单元拆分能符合预算，则停止操作，报告最小的诚实计数并附上
size:exception建议。不要迭代缩减代码以达到数字。
每个SDD工作单元应清晰地映射到一个提交或PR，并满足：
- 明确的起始状态，
- 明确的完成状态，
- 同一单元中的验证，
- 回退时不删除不相关的工作。
命令
# 提交前审查故事
git diff --stat
git diff --cached --stat
# 检查最近的提交风格
git log --oneline -5