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

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 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.

The idea in one screen

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:

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.

Installing it

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.

The commands

/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.

What the numbers actually say

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 and made four fair criticisms:

1. A single prompt-completion pair is not how agents are used.
2. The baseline was a bare chatty model that padded answers with prose and options, so "lines of the answer" was counting commentary, not code.
3. "Prefer one-liners" might trade away safety.
4. A seven-word prompt might do the same job as a whole skill.

Against that fairer baseline:

The per-task numbers are more useful than the average:

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.

Where I'd push back

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.

Is it worth a try?

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

Benchmark writeup and reproduction steps: benchmarks/results/2026-06-18-agentic.md