用途：当一项功能涉及多个文件时，按波次实现，每一波对应一个逻辑关注点，形成一个独立提交，并按依赖关系排序，从而产生可供审查者逐提交审计的干净 Git 历史。相关技能：standalone-commits 负责让每一波可审查、可审计；git 负责提交信息规范与 PR 指南。两者关系上，本技能决定提交顺序，standalone-commits 判断每个提交边界是否合理。
主要能力：规划提交序列（foundation → implementation → consumers → cleanup），并用 standalone-commits 的测试校验每一波能否作为一致单元被审查、验证和回滚，若不通过则先调整波的边界。
典型波次顺序：波1 基础（types、interfaces）→ 波2 工厂/构建器（创建实例的函数）→ 波3 契约/API（使用类型的公开接口）→ 波4 基础设施（工具、转换器、依赖）→ 波5 消费者（应用、UI、集成）。并非所有改动都需要全部波次：简单缺陷修复可能是单个独立提交，跨切面重构可能需要五波。每一波应满足：原子（一个逻辑关注点）、可构建（该波后代码可编译，运行类型检查）、聚焦（只涉及一个层/关注点）、完整（无半成品）、可审计（无需等待后续波即可审查）。
使用方式：编码前先规划波次——列出需修改的文件、按层/关注点分组、按依赖排序（基础在前）、定义每一波要证明的独立声明；实现时只改本波文件，抵制“顺手再修一个”的冲动；用 bun run tsc --noEmit 做类型检查，并对照波声明重读 git diff --staged，确保未引入错误；以约定式提交格式提交；重复进入下一波。文件依赖启发式：不导入任何文件的排在前（如 types.ts），导入全部文件的排在后（如 app/）。多波次工作可创建功能分支，逐波提交，最终 PR 展示功能演进的清晰历史。
适用场景：跨 5 个以上文件的重构、破坏性 API 变更（类型→API→消费者）、新增依赖并使用（先基础设施波后使用波）。单文件缺陷修复无需分波。
限制与反模式：避免巨型提交（无法二分定位、无法部分回滚）、微提交（一个逻辑变更拆成 20 个提交产生噪音）、错误顺序（先改消费者后加类型会无法编译，应自底向上）。资料未提供该技能的安装方式、收费、平台及效果信息。