前言¶
日常编码里容易走偏的两种情况：一种是收到需求先想抽象层、先加依赖、先分目录，最后为了改三行写了三百行；另一种是反过来，只说「已修复」，看不出改了哪几处、为什么这么改。
下面介绍的 Ponytail，就是把「最小改动」和「回复能一眼读完」写成固定规则的开发类 Skill，属于 dev-programming 分类。
这是什么¶
Ponytail，坐标 @clawhub_dietrichgebert/ponytail，来自 clawhub，发布者为 dietrichgebert，抓取到的版本号是 4.8.4。
官方简介只有一句话的定位：处理任何编码任务（编写、重构、修复、审查），遵循 YAGNI、优先使用标准库、避免不必要的抽象；并且明确不适用于非编码请求。
它不生成架构图，也不写长篇解释，约束的是改动的体量和回复的可读性。任务线索里给出的中文名是「极简懒人开发模式」，简介文字里还提到「用能完整解决问题的最小改动完成任务，回复要让忙碌的人一眼读完就懂」，这句未出现在抓取到的官方页面中，属于线索侧描述。
核心功能¶
按抓取到的官方简介，Ponytail 的能力可以拆成四条。
1、编码任务全覆盖。编写、重构、修复、审查都走同一套原则，不需要在脑子里另外维护一份规则。
2、YAGNI。当前用不到的能力不实现，包括「以后可能用到」的接口和配置开关。
3、优先标准库。能用标准库实现的功能，先走标准库，再考虑第三方依赖。
4、避免不必要的抽象。新增一层封装之前，先确认它解决了具体问题，而不是让结构看起来更整齐。
它的标签里写着 requires_api_key=false，也就是说调用时不需要额外的密钥配置。
安装与启用¶
抓取到的官方页面只给了坐标和上游仓库，没有给出安装命令或配置文件字段，因此这里不写未经核实的命令。
官方地址：https://api.skillhub.cn/org-b6kzcl68/ponytail
SkillHub 页面：https://www.skillhub.cn/skills/clawhub_dietrichgebert/ponytail
上游仓库：https://clawhub.ai/dietrichgebert/ponytail
坐标：@clawhub_dietrichgebert/ponytail
这类 Skill 基于通用的 SKILL.md 格式。落地方式是把 Skill 文件放进你所用 agent 的 skills 目录，再按该 agent 的方式引用它。Cursor、Codex CLI、Claude Code 各自的目录约定和引用语法，抓取到的资料里没有说明，这里不做区分。
需要确认最新字段时，以 SkillHub 页面和上游仓库为准，这两个页面在本文写作时都返回抓取失败。
典型用法¶
Ponytail 的用法不是某个具体函数，而是一套在动手前就生效的判断顺序。下面按这套原则给出一个重构请求的落地顺序。
1、先问改什么。把请求拆成「实际变化的那一处」，例如新增一个过滤条件，那变化就只在调用点和被调函数的参数上。
2、再看标准库有没有现成的。排序、解析、编码、路径处理这类需求，标准库通常已经覆盖，先确认再写。
3、然后才考虑新增代码。需要写的部分只包含当前请求要求的行为，不补防御性分支，不预埋扩展点。
4、最后把改动讲清楚。回复控制在几行内，写明改了哪几个位置、为什么这样做。
任务线索里还列出了一组触发词：极简方案、yagni、最简实现、别过度设计、lazy mode，并提到 lite / full / ultra 三档。抓取到的官方页面没有出现触发词，也没有档位说明，正文只按上面四条原则介绍。
适用场景与注意¶
适合的场景很明确：日常的编写、修复、重构、评审，尤其是改动本身很小、却容易被放大成一次重构的场景。
需要注意的边界：
1、官方简介写明不适用于非编码请求，用在文档撰写、数据分析解释这类任务上不匹配。
2、YAGNI 和标准库优先，意味着当你确实需要第三方能力时，要先说清标准库为什么不能满足，而不是直接引入依赖。
3、这套原则和「一次性把架构搭好」的团队习惯是冲突的。如果你所在的项目本来就有既定的分层和依赖规范，Ponytail 的规则应当服从项目规范，而不是反过来。
结尾¶
Ponytail 的价值在于把「最小改动」变成默认行为：不需要意志力去对抗过度设计，只需要在动手前确认标准库和 YAGNI 这两条。它不是用来生成更多代码的工具，是用来少写代码、写清改动的工具。
官方地址：https://api.skillhub.cn/org-b6kzcl68/ponytail
写作本文时，任务线索给出的评分 99680、下载 934 次，与抓取到的官方页面（评分 100000、下载 22086、安装 40）不一致，正文未采用线索侧数值。
