By name: shipping-changes user-invocable: false description: End-to-end change-shipping closed loop for non-trivial work — research → proposal doc → phased guarded implementation → PR self-review → harden → merge. Use when taking a substantial change from idea to merged PR, when a task needs a written proposal before code, when implementing in reversible phases behind a guarded commit chain (assert + test + verify, all green before commit), or when self-reviewing your own PR. Complements automating-devops (which is the git/CI/release knowledge reference); this skill is the orchestration spine that sequences a change from zero to merged. allowed-tools: Read
渡劫之链 · shipping-changes
大改动不是一锤子。调研定题 → 提案对齐 → 分阶段守卫式推进 → PR 自审 → 补护栏 → 合并。每一关绿了才进下一关。
何时使用
| 场景 | 使用 | 理由 |
|---|---|---|
| 一个改动牵动多文件 / 多模块 / 公共路径 | ✅ | 回归面大，值得先提案再施工 |
| 重构、架构调整、协议/格式变更 | ✅ | 需要写实蓝图 + 字段映射对齐 |
| 改动可拆成可独立 revert 的阶段 | ✅ | 守卫链分阶段，控爆炸半径 |
| 自审自己的 PR | ✅ | 用挑刺视角找自己埋的雷 |
何时不使用
- ❌ 单文件、低风险、机械改动——直接改完跑测试即可，别套流程
- ❌ 纯探索 / 一次性查询——无交付物，不进闭环
- ❌ 紧急止血(宕机/事故)——走故障链「止血→定位→修复→验证→复盘」，不在此列
七关闭环
关 0 调研定题 —— 摸清现状 + 业界最佳实践，定问题域(不臆造)
关 1 提案文档 —— docs/<topic>.md：诊断 + 蓝图 + 字段映射 + 迁移路径 + 风险回滚
关 2 对齐 —— 魔尊 review 提案；歧义/破坏性/高成本处停下确认
关 3 分阶段实现 —— 每阶段单一关注点、可独立 revert；单点 PoC 绿了再横推
关 4 守卫链提交 —— assert + test + verify 全绿才 commit；任一红即阻断，不提交
关 5 PR 自审 —— 挑刺视角过 diff，把发现挂到 PR 上(含已知取舍)
关 6 补护栏 —— 把自审揪出的隐患钉成测试，follow-up 推上分支
收口 合并 —— 确认 mergeable + CI 全绿 → merge → 同步本地 main
核心铁律:守卫链提交(关 4)
这是全链最值钱的一环——绝不提交未验证的改动。
# 守卫式链:前一步红，后续全部不执行(&& 短路),自然阻断提交
node /tmp/assert.js \ # 自定义不变量断言(如:零宏泄漏、无跨配串味)
&& npm test \ # 全量测试
&& npm run verify:skills \ # 项目专属闸门
&& git add -A && git commit -F msg.txt \
&& git push -u origin <branch>
- 任一关红 → 链断 → 不 commit：脏改动永不入库。
- 自定义 assert 优先于通用测试：通用测试覆盖不到的领域不变量,自己写脚本断言(例:渲染产物零模板变量泄漏)。
- stamp 在链尾:push / PR 放最后,网络受阻不影响已验证的本地 commit。
⚠ 反模式(血泪):别把 test 与 commit 塞进同一个
{ ...; ... }/;顺序块——块内命令各自独立执行,test 红了 commit 照样跑,守卫退化成「记录」而非「阻断」。必须用&&串成短路链,让前一关的非零退出码真正掐断后续。改了源,先想哪条旧断言要同步改,否则 test 必红。
分阶段实现(关 3)
| 原则 | 说明 |
|---|---|
| 单一关注点 | 一阶段只做一类改动(接线 / 数据迁移 / 新增层 / 测试),便于 revert |
| 向后兼容优先 | 新路径在旧产物缺省时退化为旧行为(byte-compat),降低回归风险 |
| 单点 PoC + 低风险先行 | 先拿代表性目标开刀,纯增量/行为等价的阶段先做;绿了再横推、再推中高风险阶段 |
影响面检查(关 4.5)
如果 abyss 可用（command -v abyss），提交前对每个修改过的函数跑影响面分析：
abyss impact <changed-function> --json
- risk > 7：在 PR description 中标注「高影响变更」+ 列出影响面
- uncovered paths > 0：在 PR description 中标注「需补测试」+ 列出未覆盖路径
- 耦合文件未同步修改：提醒检查
abyss map中的 coupling 对
PR 自审(关 5)
挑刺视角,按等级分类挂到 PR:
- 🟡 应在本 PR 或紧随处理:缺护栏的回归风险、新行为无专属测试
- 🟢 设计取舍(记录在案):与理想方案的有意偏差、宿主限制
- ⚪ 可选打磨:美观瑕疵、风格统一
自审要诚实标注「已知不一致仍在」「为兼容做的妥协」,而非粉饰。误报要核实后澄清(例:扫描器把角色名当人称漏网)。
收口
- 每关都要落到:结论 + 动作 + 验证 + 风险 + 下一步。
- 合并前确认:
mergeable=CLEAN+ CI 全绿;合并后同步本地 main,删远端分支。 - 闭环留尾:未做的阶段(如更深的重构)记入提案文档的「余劫」,标为独立后续。
参见 automating-devops——git/CI/release 的知识底座;本 skill 只管「怎么把一个改动从零推到合并」的编排。