审查 diff 中的过度工程：当变更可能过度设计时…

适用于需要快速审查代码 diff 是否过度复杂、依赖过多或抽象多余，并希望得到一行一条删减建议的场景。

适用场景

解决思路

1. 审查 diff 中不必要的复杂度。
2. 每个发现只写一行：位置、要删什么、用什么替换。
3. 以让 diff 变短为最佳结果，优先识别可删除、可内联、可替换的内容。
4. 按格式输出：`L<line>: <tag> <what>. <replacement>.`；多文件 diff 用 `<file>:L<line>: ...`。
5. 使用 `delete:` 标记死代码、未使用的灵活性、推测性功能；替换项写 nothing。
6. 使用 `stdlib:` 标记手写的标准库已有能力；指出具体函数名。
7. 使用 `native:` 标记依赖或代码做了平台已支持的事；指出具体平台特性。
8. 使用 `yagni:` 标记只有一个实现的抽象、没人设置的配置、只有一个调用方的层。
9. 使用 `shrink:` 标记相同逻辑可用更少行数表达；展示更短写法。
10. 参考示例给出具体替换：stdlib 用 `@` in email 检查替换 27 行 validator，真实验证靠确认邮件；native 用 `Intl.DateTimeFormat` 替换 moment.js；yagni 内联 AbstractRepository 直到出现第二个实现；delete 删除幂等本地调用的 retry wrapper；shrink 用 `dict(zip(keys, values))` 替换手工循环。
11. 结尾给出唯一指标：`net: -<N> lines possible.`
12. 如果没有可删内容，输出 `Lean already. Ship.` 并停止。
13. 单个 smoke test 或基于 assert 的自检是 ponytail 最低要求，不算膨胀，绝不要标记删除。
14. 不应用修复，只列出建议。
15. 收到 `stop ponytail-review` 或 `normal mode` 时，恢复为冗长 review 风格。

适用边界 · 注意事项

• 当需要检查正确性 bug、安全漏洞或性能问题时，不要用此技能；这些不在范围内，应转给普通 review pass。
• 当希望直接应用修复或修改代码时，不适用；此技能只列建议。
• 当需要冗长讨论式 review 而不是一行一条的删减清单时，不适用。