Ponytail
让编码代理先复用和原生能力，再写最小且保留安全边界的实现。
按维度查看评分与理由
证据显示：插件通过生命周期钩子注入指令，需要用户授权（如Codex要求审查hooks）；有配置文件和环境变量控制模式；未发现敏感数据处理或外部网络请求；依赖较少，但未提供依赖审计；有卸载脚本和回滚机制（如插件卸载）；来源归属明确（作者和仓库）。扣分：权限最小化未明确说明，用户确认机制仅部分体现，数据流透明度有限，敏感数据处理未提及，依赖安全未审计，外部影响未明确，回滚机制仅部分，来源归属虽明确但未验证。
证据显示：测试覆盖了多个边界情况，如缺失事件和systemPrompt；依赖包括Node.js和Python，但未明确版本范围；失败消息在测试中有体现，但未系统化。扣分：依赖可用性未充分保证，失败消息不够全面。
证据显示：支持多种代理（Claude Code, Codex等），有明确的安装说明和命令；能力边界通过模式（lite/full/ultra）和命令（review, audit等）定义；触发精度通过技能描述和命令实现；环境适配考虑了不同代理的配置。扣分：部分适配器仅指令模式，功能受限。
证据显示：有清晰的目录结构和文档；安装说明详细；命名稳定（命令和技能名称一致）；有示例和FAQ；已知限制在README中提及；MIT许可证明确；版本号存在但无changelog；维护责任由作者承担但未明确。扣分：版本变更记录缺失，维护责任未明确。
证据显示：输出可用性通过命令和技能实现；边际价值在于减少代码量；成本效益通过基准测试声称。扣分：基准测试未独立验证，成本效益数据可能夸大。
证据显示：README中引用了基准测试报告和issue；但未提供原始数据或独立验证；事实与推断混合。扣分：声明可追溯性不足，交叉验证缺乏，事实与推断分离不清晰。
- 基准测试声称的代码减少和成本节省未独立验证，可能夸大。
- 依赖安全未审计，建议检查依赖漏洞。
- 插件通过生命周期钩子注入指令，需确保用户授权和审查。
这个 Agent 能做什么，适合哪些场景？
Ponytail 是面向编码代理的规则集与插件，目标是减少不必要的实现，而不是单纯压缩回复。它要求代理在动手前依次判断需求是否应存在、是否可复用现有代码、标准库、原生平台能力或已安装依赖。仓库提供 Claude Code、Codex、GitHub Copilot CLI、OpenCode、Gemini CLI 等多种宿主的安装或规则文件接入方式。支持技能的宿主可使用模式切换、差异评审、全仓审计和延后事项台账等命令；指令式接入则只加载常驻规则。其基准说明是在 FastAPI 与 React 的真实开源项目中，以 Claude Code 会话和 git diff 衡量代码行数、令牌、成本、耗时与安全检查结果。
Ponytail 在代理理解并阅读相关代码路径后，按“是否需要存在 → 是否已有实现 → 标准库 → 原生平台 → 已安装依赖 → 一行代码 → 最小实现”的阶梯选择方案，并明确保留输入校验、数据丢失处理、安全和无障碍要求。Claude Code 和 Codex 插件使用两个 Node.js 生命周期钩子；Codex 安装后可在 /hooks 中审阅并信任它们，随后规则会在会话中生效。它可通过 /ponytail 或对应技能设置 lite、full、ultra、off 模式；/ponytail-review 针对当前 diff 产出可删除项，/ponytail-audit 检查整个仓库，/ponytail-debt 汇总 ponytail: 延后项，/ponytail-gain 显示基准记分板。README 还说明，激活时规则可注入通过 Agent 工具生成的子代理，并可用 PONYTAIL_SUBAGENT_MATCHER 限定匹配的 agent_type。
- 使用 Claude Code 或 Codex 修改功能的开发者，希望在实现前先检查现有代码、标准库和浏览器原生控件是否已能满足需求。
- 正在审查当前 git diff 的团队成员，需要通过 /ponytail-review 获得针对过度工程的删除清单。
- 维护已有项目的工程师，需要运行 /ponytail-audit 查找不只存在于当前改动中的过度实现。
- 在 Cursor、Windsurf、Cline 或 GitHub Copilot Chat 中工作的开发者，愿意复制仓库提供的对应规则文件以获得常驻指导。
- 使用支持技能的宿主进行复杂改动的用户，需要以 /ponytail ultra 提高最小化规则的强度，或以 off 暂时关闭。
这个 Agent 有哪些优点和局限？
- 采用明确的决策阶梯，优先跳过需求、复用既有实现、标准库和原生能力，而非只要求生成更短的代码。
- 同时提供常驻规则、插件和技能命令，覆盖 Claude Code、Codex、Copilot CLI、OpenCode、Gemini CLI 等多种宿主。
- 提供具体的工程工作流：当前 diff 删除清单、全仓过度工程审计、延后项台账和基准记分板。
- README 的代理式基准使用真实 FastAPI + React 仓库及 git diff，并公开说明了旧单次生成基准的局限。
- Claude Code 与 Codex 的常驻激活依赖两个 Node.js 生命周期钩子，且 node 必须位于非交互式 shell 的 PATH；否则技能仍可用，但自动激活会保持静默。
- 不同宿主的能力并不一致：部分平台仅能加载规则，模式切换和命令需要支持技能的宿主。
- README 中的量化结果来自 12 个功能任务、Haiku 4.5、n=4 以及单一 FastAPI + React 仓库，不能直接视为所有模型和代码库的效果保证。
- 仓库说明 GPT-5.5 等会在阶梯上消耗更多思考令牌的模型，成本和延迟可能反向变化。
如何安装或部署这个 Agent？
Codex：先确保 node 位于非交互式 shell 的 PATH 中，然后运行：
codex plugin marketplace add DietrichGebert/ponytail
codex plugin add ponytail@ponytail启动 codex，打开 /hooks 审阅并信任两个生命周期钩子，再开启一个新线程。README 未列出额外凭据要求。若只需规则式接入，可按宿主复制相应文件；例如 Cursor、Windsurf、Cline、Copilot、Kiro 和 Qoder 分别使用仓库中对应的规则文件或 AGENTS.md。
如何使用这个 Agent？
在 Codex 的新线程中，以技能形式调用，例如：@ponytail-review。使用 /ponytail lite、/ponytail full、/ponytail ultra 或 /ponytail off 切换强度；不带参数时报告当前级别。默认级别为 full，可用 PONYTAIL_DEFAULT_MODE，或 ~/.config/ponytail/config.json 中的 defaultMode 设置新会话默认值。要限制对子代理的规则注入，可设置 PONYTAIL_SUBAGENT_MATCHER 为匹配 agent_type 的不区分大小写正则表达式。
这个 Agent 与同类方案有什么区别？
Ponytail 将自己与 caveman 区分：README 将 caveman 描述为缩短代理说话方式、保持代码不变，而 Ponytail 聚焦缩小实际构建的代码。其基准还比较了“YAGNI + one-liners”提示词；README 报告该提示词在单独的对抗安全层中为 95%，Ponytail、无技能基线和 caveman 为 100%。