What it is and why it matters
You ask Claude for a calendar to pick a date, and it builds one from scratch: 335 lines to read and to fix when they break. Yet your project already had its own input field, and every browser already has a calendar. Ten lines would have done it.
ponytail puts a lazy senior developer inside your Claude, lazy in the good sense. Before writing, it reads the code the change touches and looks for what already exists: in the project, in the browser or the language, in the libraries you have installed. Then it writes only what's missing. It doesn't cut the checks, though, and where money or security is involved it leaves a small test behind.
It's a prompt (a skill, that is an instruction file for Claude) plus a plugin that loads it every session. Free, MIT license, more than 180,000 stars on GitHub at the end of October. Its author measured it on 39 tasks: on average 53% fewer lines and 26% lower cost. How to read them: step 6. It's for anyone building alone with Claude Code who doesn't want to reread useless code.
1. Install it in Claude Code
Open Claude Code and send these two lines as two separate messages: in a single one, the install guide says, it doesn't work.
/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail
The first adds the marketplace, the catalog Claude Code takes the plugin from. The second opens the plugin's details: read what it installs and choose «Install for you», so it applies to all your projects. In the desktop app, Code tab, type the same lines into the prompt box.
To check that it's on:
- In /plugin, Installed tab, ponytail is there.
- At the start of every session ponytail shows the active level.
- /ponytail on its own tells you the level; if it was off, it turns it on.
Other agents: copy the repo's AGENTS.md file into your project (rules always on, no commands) or follow INSTALL.md.
2. How it thinks: the ladder before writing
The heart of ponytail is a ladder. It reads the task and the code it touches, then stops at the first rung that solves the whole thing:
- Does it need to exist? What nobody asked for gets skipped, and it tells you in one line.
- Is it already in the project? A component or a function you use elsewhere: it uses that.
- Does the language or the browser do it? It uses that, but a component from the project comes first.
- Does a library you already installed do it? Never a new library for a few lines.
- Will one clear line do? One line.
- Only then the minimum code that works, with a small test if there's logic in it.
The calendar comes from its benchmark, with the request «add a date picker». Without ponytail, 335 lines. With ponytail, 10, which reuse the project's Input component with type="date": the browser brings the calendar. Honestly: it's the most extreme case of the 39 tasks. On many small tasks the difference is small or none.
To watch it work, ask like this (change the parts between [ ]):
Add [a date picker] to [the booking form]. Before writing, tell me what already exists in the project, in the browser or in the installed libraries that does this job, and which rung you stopped at.
3. The three intensity levels, and off
It starts by itself, at the full level. You change it with /ponytail and the level, until the session ends.
- lite: it does what you asked and suggests the smaller version in one line. I use it when the request is already decided.
- full: the ladder from step 2, with a test where it's needed. It's the one I keep almost all the time.
- ultra: on top of that it questions the request and, before building, tells you what the need doesn't justify. I use it at the start of a project.
- off: turns it off. A message with only «stop ponytail» works too.
/ponytail ultra
To change the starting level of every session, write it in ~/.config/ponytail/config.json (on Windows in %APPDATA%\ponytail):
{ "defaultMode": "lite" }Or there's the PONYTAIL_DEFAULT_MODE environment variable, which wins over the file. With "off" it doesn't start by itself: you turn it on with /ponytail.
4. The two review commands
Both write a report and don't touch the code. Every problem is numbered and says what that code does, what goes wrong, how to fix it and what happens if you leave it. The report is usually in simple English.
/ponytail-review: the change you just made
On its own it looks at the changes not yet in a commit, or at the last commit if there are none. It also reads the code that uses them, because a change can break a file you didn't touch. To choose what it looks at, add a word: uncommitted, staged (ready for the commit), branch or a PR link.
/ponytail-review branch
Then answer with the numbers:
Fix 1 and 3 with the smallest fix you proposed. Leave the others.
/ponytail-audit: the whole project, ranked
Same checks, on the whole repo or on the folder you name. First it maps it: where data comes in, where it ends up, how much load it must handle. Then it ranks at most 20 problems, worst first, and tells you where to start. I run it on a project I haven't opened in months.
/ponytail-audit
If the Claude Code menu shows the commands with the plugin's name in front, like /ponytail:ponytail-review, use that form.
5. The marked shortcuts and the band above the prompt
When it picks a shortcut with a known limit, ponytail writes it in the code with a shortcut: comment followed by the limit and when to change it. For example a list kept in memory that holds while users are few. They're decisions, not mistakes, but they need rereading: /ponytail-debt collects them in a ledger and flags the ones that don't say when to revisit them.
/ponytail-debt
Write this ledger to PONYTAIL-DEBT.md.
With a recent Claude Code, in the terminal and the desktop app, there's a band above the prompt: how much the task is using, the agent's time, how much code it reused, whether the tests passed. /ponytail band hides it and brings it back.
6. The numbers, read honestly
These are its author's own numbers: 39 tasks, Claude Code with Opus, 5 runs per task. The method and the scripts are in the repo.
- Lines of code: 53% fewer on average (between 41% and 63%).
- Cost: 26% lower at list price (between 16% and 36%). On a subscription you don't pay less: you use less of your limit.
- A test where the logic calls for one: 98% of the time, against 68% without ponytail.
- Correctness, on the 18 tasks with hidden checks: level. Less code didn't take away safety, but it didn't add any either.
In the benchmark the agent couldn't run commands: it measures what it writes, not how it works in your project. And ponytail is still a prompt: Claude can get it wrong anyway, and you reread the shortcuts.
Common mistakes
- Sending the two install lines in a single message.
- Installing it from a copy: the original is only DietrichGebert/ponytail on GitHub (or @dietrichgebert/ponytail on npm) and never contains .exe or .dll files.
- Not having Node.js: the instructions work, but every message shows the error «node: command not found».
- Leaving the shortcut: comments unread: the limit they state comes sooner or later.
Checklist
- I sent the two install lines as two separate messages
- Typing /ponytail I see the active level
- I tried /ponytail-review on a real change of mine
- I read the shortcuts with /ponytail-debt
Frequently asked questions
Is ponytail free?
Yes, MIT license. Claude's answers still count against your usage, as always.
Does it cut security checks too?
No. Validating data that comes from outside, error handling that prevents data loss, security and accessibility are never cut. On the benchmark's six security tasks: 30 runs out of 30, same as without ponytail.
What if I really need the long solution?
Ask for it plainly: the instructions say never to cut anything you asked for. Or switch to lite.