jackwener /small-diff · 最小改动模式
使用场景
- 修线上 bug（review 成本高，越小越好）
- 在多人协作的核心模块里改代码（不能顺手 rename）
- 在不熟的代码区域改代码（不知道改动的辐射范围）
- 老项目维护（历史代码风格不一致，但改了风格 = 引入风险）
任何时候**用户明确说"最小改动"**也立即启用本 Skill。
目标
让每个 diff 小、明确、可解释。Agent 默认倾向于"既然来了我顺手优化一下"——/small-diff 是对抗 scope creep 的工程手段。
必须步骤
1. 列出"必须改"的最小集合
按"完成任务必须改"的角度筛选：
- 删掉一切"可改可不改"的修饰
- 删掉一切"看起来更好但不解决问题"的重构
- 删掉一切"顺手"的命名 / 顺序调整
2. 解释每一处 diff 的必要性
对每一处改动回答：
- 为什么必须改？（任务直接要求 / 修 bug 必经路径 / 其他改动的依赖）
- 为什么不能更小？
如果回答不出，删掉这处改动。
3. 不允许做的事
| 行为 | 原因 |
|---|---|
| 顺手 rename 变量 | 增加 review 成本 |
| 顺手 format 整个文件 | 把 diff 噪音放大 10 倍 |
| 顺手抽象出 helper 函数 | 任务不需要、引入新决策点 |
| 顺手"现代化"语法（switch → match） | 风险 vs 收益不成比例 |
| 顺手补 type | 除非这处 type 是 bug 的根因 |
| 顺手删 dead code | 留给独立的 cleanup PR |
| 顺手改测试期望值 | 永远不要——这是 reward hacking 红线 |
4. 必须做的事
- 不变的不动：即便看到丑代码也忍住
- 改动集中在最少的文件 / 最少的函数
- 新增导出 / 新增 props 必须在调用方有真实需求
- 改函数签名前先 grep 所有调用方，确认改动可控
5. 最终自审
git diff --stat | wc -l
如果改了超过 5 个文件，或者超过 200 行，停下重新评估：
- 是不是任务确实需要这么大改？
- 能不能拆成多个 PR？
禁止事项
- ❌ 用"顺便"作为加改动的理由
- ❌ 用"现代化"作为重写的理由
- ❌ 用"代码风格不一致"作为格式化整文件的理由
- ❌ 用"为了将来扩展"作为新增抽象的理由（YAGNI 原则）
- ❌ 改测试期望值让红的变绿（除非测试本身确认是错的，且解释清楚为什么）
输出格式
## 改动范围
- 文件 N 个，行数 M
- 涉及：lib/xxx.ts、app/api/yyy/route.ts
## 每处改动 + 必要性
1. `lib/xxx.ts` line 42-45：添加 fooBar() 调用 → 因为... 不加不能完成任务
2. `app/api/yyy/route.ts` line 10：从 body 取 examId → 因为... 路由本身需要
## 主动放弃的"顺手"
- 看到 lib/xxx.ts 里有未用 import，没动（留给独立 cleanup）
- 看到 app/api/yyy/route.ts 的错误处理可以更优雅，没动（不在任务范围）