17 万 star 的 prompt skill：让你的 agent 像"最懒的资深工程师"一样思考

vibe coding 的瓶颈从来不是"写不出"，是 agent 太勤快——上来就装库、造轮子、写一堆没人维护的代码。DietrichGebert/ponytail 这个 prompt skill 反直觉地用"懒"治"快"：核心理念是"最好的代码是没写的那行"。

它给 Claude Code、Codex、Cursor 等 20 多个 agent 用，仓库 170,674 star（GitHub 公开数据，MIT 协议），今天还挂在 GitHub 日榜上。机制很简单，叫"复用阶梯"：动笔写代码之前，agent 必须先过四问——这需求真的存在吗？仓库里已经有吗？标准库/浏览器原生能力/已装的依赖能搞定吗？都过不去，才写最小实现。

项目方自报的 benchmark（方法公开在仓库 benchmarks/results/2026-10-07-agentic.md，39 个任务×5 轮、用 Opus 5.5 跑）：代码量 -53%、耗时 -41%、成本 -26%、token -45%；98% 的风险逻辑带测试上线（没用 skill 的对照组只有 68%）。5.3 版本还加了个"the band"：在 Claude Code 提示符上方显示本任务的成本、token、复用率、测试状态看板——烧了多少钱一眼可见。

安装就一条命令：

/plugin marketplace add DietrichGebert/ponytail

对谁有用：所有用 agent 写代码的人，尤其是 vibe coder。你的 agent 每装一个新依赖，都是一笔未来的维护债。Ponytail 不省测试、不省安全、不省校验（这点和今天 14:54 那篇"10 月 coding-agent 卷审代码"的风向帖互文），它省的是"本来就不该写的代码"。

独立判断：这个思路对"屎山仓库接手"场景价值最大——让 agent 先读懂再动手，而不是先动手再读懂。未经实测，个人判断：benchmark 是项目方自报，真实收益取决于你的仓库结构，建议先在小任务上试一周，对比 token 账单再决定全量用。

可信度：star 数为 GitHub 官方数据；benchmark 与功能描述为项目方自报（方法公开可查）。