Ponytail: the AI coding skill that makes your agent write less code

Ponytail, an open-source skill for AI coding agents, aims to reduce code bloat by enforcing a 'ladder' of rules that prioritize reuse and minimal code. The project, created by Dietrich Gebert, works with Claude Code, Codex, Cursor, and other agents, and includes commands like /ponytail-review to audit diffs for over-engineering. The original benchmark claimed 80-94% less code, though a GitHub issue raised questions about the methodology.

You ask your AI agent for a date picker. It installs flatpickr, writes a wrapper component, adds a stylesheet, sets up a theme override, and then starts explaining timezone handling to you. Four hundred lines later you have a date picker. The senior dev sitting two desks over would have written this: <input type="date" Ponytail https://github.com/DietrichGebert/ponytail is an open-source skill/plugin that tries to put that person inside your coding agent. It works with Claude Code, Codex, Cursor, Gemini CLI, Copilot, OpenCode, Windsurf, Cline, and a long list of others. MIT licensed. Ponytail is not a tool, a library, or a model. It is a ruleset that gets injected into your agent's context every turn. The core of it is a ladder. Before writing any code, the agent stops at the first rung that holds: php 1. Does this need to exist? - no: skip it YAGNI 2. Already in this codebase? - reuse it, don't rewrite 3. Stdlib does it? - use it 4. Native platform feature? - use it 5. Installed dependency? - use it 6. One line? - one line 7. Only then: the minimum that works That's basically it. Everything else in the repo is packaging: adapters for twenty-odd agents, a few slash commands, and a benchmark harness. Two things about the ladder that matter more than they look: It runs after understanding, not instead of it. The rules tell the agent to read the code the change touches and trace the actual flow before picking a rung. Lazy about the solution, not about reading the codebase. Validation is off the table. The rules explicitly protect trust-boundary validation, error handling, security, and accessibility. The stated goal is not "fewest tokens." It is "write only what the task needs." The code comes out small because the extra was never needed, not because it was golfed down. Pick your agent. For Claude Code, two prompts they have to be sent separately : /plugin marketplace add DietrichGebert/ponytail /plugin install ponytail@ponytail Codex: codex plugin marketplace add DietrichGebert/ponytail codex plugin add ponytail@ponytail Copilot CLI: copilot plugin marketplace add DietrichGebert/ponytail copilot plugin install ponytail@ponytail Gemini CLI: gemini extensions install https://github.com/DietrichGebert/ponytail For Cursor, Windsurf, Cline, Kiro, Aider, and Copilot Chat there is no plugin layer, so you copy the matching rules file out of the repo .cursor/rules/ , .windsurf/rules/ , .clinerules/ , and so on . Several agents also auto-load AGENTS.md from the project root, and the repo ships one, so those work with zero setup from a checkout. The Claude Code and Codex plugins run two small Node lifecycle hooks, so node needs to be on your PATH. If it isn't, the skills still work; you just lose the always-on activation. | Command | What it does | |---|---| | /ponytail lite\ | full\ | {% raw %} /ponytail-review | Reviews your current diff for over-engineering, hands back a delete-list. | /ponytail-audit | Same, but across the whole repo instead of the diff. | /ponytail-debt | Collects the ponytail: shortcuts you deferred into a ledger. | /ponytail-gain | Shows the measured impact scoreboard. | /ponytail-help | Quick reference. | /ponytail-review is the one I'd reach for first even if you never turn on always-on mode. Pointing it at a diff you already wrote is a low-commitment way to see whether the discipline finds anything real in your codebase. Commands need a skill-capable host. The instruction-only adapters Cursor, Windsurf, Cline, Copilot Chat, Kiro get the always-on ruleset but not the commands. This is where the project gets more interesting than most GitHub trending entries, and it's worth walking through because the story has a plot twist. The original benchmark claimed 80-94% less code. Someone opened issue 126 https://github.com/DietrichGebert/ponytail/issues/126 and made four fair criticisms: Against that fairer baseline: | vs no-skill baseline | LOC | tokens | cost | time | safe | |---|---|---|---|---|---| | ponytail | -54% | -22% | -20% | -27% | 100% | | caveman terse prose | -20% | +7% | +3% | +2% | 100% | | "YAGNI + one-liners" prompt | -33% | -14% | -21% | -30% | 95% | The per-task numbers are more useful than the average: | task | baseline | ponytail | |---|---|---| | date picker | 404 | 23 | | color picker | 287 | 23 | | file dropzone | 251 | 95 | | multi-step wizard | 571 | 312 | | search items by title | 44 | 44 | | export items as CSV | 36 | 33 | | count user's items | 21 | 17 | The shape is clear. Where there is an over-build trap, the cut is enormous, because the agent reaches for <input type="date" instead of building a component. Where the code is already minimal backend CRUD , every arm converges and ponytail does nothing. The -54% headline is an average across both kinds of task, so treat it as "huge sometimes, zero other times," not "half your code everywhere." The safety tier is the part I found most convincing. Six tasks seed a starter file, ask for one function, and leave the safety requirement implicit the way a real ticket does. The scorer then executes the produced function against adversarial input: path traversal, SQL injection, a forged token, a malformed CSV row. On the path-joining task, the bare one-liner prompt wrote the fewest lines 6 and let a ../../ filename escape the directory one run in four. Ponytail wrote about 9.5 lines and held 4/4. The extra three lines were the traversal check. That is the whole argument for using a structured ruleset instead of telling your agent "be brief." Two more things I'll credit them for. The benchmark writeup has a limitations section that names its own weak points one model only, n=4, safety is a floor and not a proof . And it documents a contamination bug they found in their own earlier run, where the plugin's SessionStart hook was firing on the baseline arm too, secretly running ponytail against itself. Finding and publishing that is a better trust signal than any number in the table. It's a prompt, not a guarantee. Everything here is instructions in a context window. Models drift, ignore rules under load, and behave differently across vendors. Nothing enforces the ladder. The gains depend on your agent being bad in a specific way. The wins come from an agent that over-builds. If you're on a stronger model, or you already write tight tickets that say "use a native input," a lot of that headroom is already gone. The README itself notes the effect can invert on some reasoning models that spend extra thinking tokens deliberating the rungs. Yes, with a caveat about which "yes" this is. The cost of trying is two commands and a slash command to turn it off. There's no runtime, no dependency in your project, no lock-in, and the uninstall is documented including a cleanup script for the state it writes outside the plugin folder . At that price, the question is barely worth deliberating. Repo: github.com/DietrichGebert/ponytail https://github.com/DietrichGebert/ponytail Benchmark writeup and reproduction steps: benchmarks/results/2026-06-18-agentic.md https://github.com/DietrichGebert/ponytail/blob/main/benchmarks/results/2026-06-18-agentic.md