shipping-changes
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.
git clone --depth 1 https://github.com/telagod/code-abyss /tmp/shipping-changes && cp -r /tmp/shipping-changes/skills/shipping-changes ~/.claude/skills/shipping-changesSKILL.md
<!-- safety-scan: ignore TOOLS_PRIVILEGED 知识型 skill,仅 Read;文中 git/gh/npm 命令由 agent 自有工具执行,非本 skill 落盘运行 -->
# 渡劫之链 · 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)
> 这是全链最值钱的一环——**绝不提交未验证的改动**。
```bash
# 守卫式链:前一步红,后续全部不执行(&& 短路),自然阻断提交
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`),提交前对每个修改过的函数跑影响面分析:
```bash
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](../automating-devops/SKILL.md)——git/CI/release 的知识底座;本 skill 只管「怎么把一个改动从零推到合并」的编排。Analyzes code changes, detects documentation drift, and evaluates change impact scope. Use when reviewing diffs, checking doc sync, or running pre-commit analysis. Automatically triggered after design-level changes or refactoring.
Scans code for security vulnerabilities, detects dangerous patterns, and ensures security decisions are documented. Use when running security scans, auditing code, or checking for OWASP issues, injection risks, or sensitive data leaks. Automatically triggered on new modules, security-related changes, or post-refactor.
Processes Excel spreadsheet files (.xlsx, .xlsm, .csv). Creates workbooks, builds formulas, preserves formatting, analyzes tabular data, and validates financial models with zero-formula-error delivery. Use when working with spreadsheet files or tabular data analysis. Do NOT use for Word documents, PDFs, presentations, or database pipelines.
Frontend UI design system selector and implementation guide covering Glassmorphism, Liquid Glass (Apple-style), Neubrutalism, and Claymorphism. Use when building UI components, choosing a visual aesthetic, implementing design tokens, or auditing accessibility/contrast on themed surfaces. Provides per-style tokens, component patterns, dark mode, and a11y constraints.
安全架构与治理:威胁建模 (STRIDE/PASTA/LINDDUN)、零信任身份架构、IAM/SSO/MFA/PAM、合规框架 (SOC2/PCI/HIPAA/GDPR)、DLP、隐私工程、安全控制设计。Use when designing security architecture, threat modeling new systems, implementing zero-trust identity, designing IAM/SSO/PAM, building compliance evidence chains, or planning privacy-by-design.
DevOps knowledge reference covering Git workflows, testing strategies, DevSecOps, release pipeline orchestration (release.yml, multi-arch images, cosign integration), CI/CD pipelines, database management, observability, and performance optimization. Use when working with Git, CI/CD, release pipelines, ghcr image publishing, testing, monitoring, or infrastructure automation.
AI agent and LLM system engineering reference covering single-agent dev (ReAct, tool calling, plan-execute), multi-agent coordination (swarm, role decomposition, file locking), LLM security (prompt injection, jailbreak defense, output filtering), RAG architecture (chunking, hybrid retrieval, rerank), and prompt engineering / evaluation (RAGAS, LLM-as-Judge). Use when building AI agents, designing RAG pipelines, orchestrating multi-agent workflows, hardening LLM apps, or writing prompts.
Checks code quality metrics including complexity, duplication, naming conventions, and function length. Use when running quality gates, reviewing code smells, or checking lint rules. Automatically triggered on complex modules or post-refactor.