Ponytail — The Lazy Senior Dev Skill for the Smallest Complete Change

Ponytail is a coding instruction skill that pushes an agent toward the smallest change that fully solves the task, with lite, full, and ultra modes. This page covers the core SKILL.md, not the plugin's hooks, band, or dashboard.

October 22, 2026
skillsponytailminimalismyagnicodingclaude-code
Ponytail — The Lazy Senior Dev Skill for the Smallest Complete Change

Ponytail

Ponytail is a coding instruction skill with a narrow thesis: the best code is the code never written. It tells an agent to understand the task and the code it touches, then take the first option that fully works: skip what nobody asked for, reuse what exists, prefer the standard library, prefer an installed dependency, and only then write the minimum.

The project is much larger than the skill. It ships a Claude Code plugin, hooks, a cost/token "band," a local dashboard, and review/audit commands. This page covers the core skills/ponytail/SKILL.md only. The plugin surface has not been reviewed here, and the author's benchmark numbers have not been reproduced.

Source and revision

FieldValue
MaintainerDietrich Gebert (DietrichGebert)
Canonical sourceskills/ponytail/SKILL.md at df9e899
Revision inspecteddf9e89941d50419fd5bcf1de41e28097f1db49b2, updated 2026-10-16
Access date2026-10-23
LicenseMIT (LICENSE, copyright 2026 DietrichGebert)
Install unitskills/ponytail/ for the core skill; the plugin is a separate package

What the core skill actually does

The skill has four parts:

1. Read before writing

Read the task and the code it touches. List every place the change must reach: callers, tests, fixtures, config, exports. Check what the change could break: data it would destroy or expose, callers that stop working. That is the scope. Extra features are not.

2. The smallest complete change

Take the first option that fully works:

  1. Does it need to exist? Skip features, options, and flexibility nobody asked for.
  2. Already in the codebase? Use the existing helper, component, service, or pattern the way the surrounding code does.
  3. Standard library or platform feature? Use it, unless the project has its own.
  4. Installed dependency? Use it. Never add a dependency for a few lines.
  5. Can it be one line a reader gets at a glance? One line.
  6. Otherwise, the minimum code that works.

The skill is explicit that this is not permission to under-deliver. "Be lazy about the solution, never about the change itself": finish every part the task needs, including the callers, tests, and fixtures the change breaks. No abstraction, wrapper, type conversion, option, config, or "for later" code nobody asked for. Deletion beats addition. Keep the codebase's existing structure.

3. Never cut these

Validation at trust boundaries, error handling that prevents data loss, security, accessibility, the calibration real hardware needs, and anything the user asked for.

New non-trivial logic (a branch, a loop, a parser, money or security, or a whole new script or app) leaves one small test or an assert-based self-check. Trivial changes need none.

A deliberate shortcut gets a comment in this form:

shortcut: <the limit>, <when to upgrade>

4. End with the risk

Every reply ends with one or two lines: what was skipped or not checked, and any risk the user must know. That is the honesty mechanism. A small change with an undisclosed limitation is not the same as a small complete change.

The three levels

LevelBehavior
liteBuild what was asked. Name the smaller option in one line and let the user pick.
fullThe rules above. Default.
ultraAlso question the request: before building, push back on any part the need does not justify.

The skill stays active for the whole session until the user says "stop ponytail" or "normal mode." The README says the level can be switched with /ponytail lite|full|ultra on hosts that support the plugin commands.

Illustrative task

This is a constructed example, not a benchmark.

Request: "Add CSV export to the admin orders page."

Ponytail pass:

  1. Does it need to exist? Yes, the user asked for it. Do not add scheduled exports, email delivery, or a column picker.
  2. Already in the codebase? The admin page already has a downloadFile helper and the orders query already supports filters. Reuse both.
  3. Standard library or platform feature? The runtime has a CSV escaping utility in the shared export module. Use it; do not add a CSV package.
  4. Installed dependency? No new dependency needed.
  5. One line? No, the endpoint and the button wiring are separate.
  6. Minimum that works: one route that reuses the orders query, one helper call, one button. Add a test for a value containing a comma and a quote.

End-of-reply disclosure: "Skipped column selection and streaming; the current export loads all filtered rows into memory. If order volume grows past the page limit, switch to a streaming writer."

That is the behavior the skill is trying to produce: a complete change, an explicit non-goal, and a risk the user can act on.

When to use it

  • You want an agent to stop adding speculative abstractions and dependencies.
  • You are working in a codebase with existing helpers and conventions.
  • You want an explicit statement of what was skipped and what risk remains.
  • You are reviewing a change for unnecessary surface area.
  • You want a lightweight, always-on coding posture rather than a full workflow framework.

When not to use it

  • You need a feature designed from scratch with exploration and trade-off analysis. ultra mode questions the request, but the skill is still biased toward the smallest version.
  • You need a security review, a migration plan, or an architecture decision record. The skill says not to cut security, but it does not provide a security method.
  • You want a plugin's hooks, cost band, dashboard, or review commands. Those are separate surfaces and have not been reviewed here.
  • The task is intentionally exploratory, such as a spike or a prototype whose purpose is to learn. "Smallest complete change" can cut the exploration that makes the spike useful.
  • You need a guarantee that the agent will not under-build. The skill is text; the host can ignore it.

Install

The core skill can be installed without the plugin. That is the recommended route if you only want the instruction set.

npx skills add DietrichGebert/ponytail --skill ponytail -a claude-code

Prerequisites and footprint

ItemDetail
RuntimeAny agent that loads instructions
Files (core skill)One SKILL.md, about 3,500 bytes
Scripts (core skill)None referenced; the plugin package has scripts and hooks of its own
Network (core skill)None
Credentials (core skill)None
WritesCode changes you approve
Plugin footprintHooks, commands, optional local dashboard; not reviewed here

The core skill is one of the smallest installs in the collection. The plugin is not. Keep the two scopes separate when you evaluate risk.

The package is not the skill

The README describes:

  • Claude Code and Codex plugin installs with lifecycle hooks.
  • A "band" above the prompt showing cost, tokens, agent time, reuse, and test status.
  • A local board that stores session data under ~/.config/ponytail/band/.
  • /ponytail-review, /ponytail-audit, /ponytail-debt, /ponytail-gain, and /ponytail-help commands.
  • A shortcut: comment ledger.
  • Benchmark results from a 39-task, 5-run comparison in Claude Code with Opus 5.5, including code, time, cost, token, and test-rate claims.

None of that package surface is covered by this page's review. The hooks execute code; the band stores local data; the benchmark is author-run. If you install the plugin, review those components separately and decide whether you want lifecycle hooks in your agent.

Limitations

  • Under-building is a real failure mode. A vague request gets the smallest version that does the core job. If you wanted the larger version, say so.
  • "Smallest" is judged after reading, not before. The skill says to read the code and callers first. An agent that skips that step will produce a small but wrong change.
  • The risk disclosure is not enforced. The skill asks for it; a host can omit it.
  • No measurement. The benchmark claims are the author's and were not independently reproduced.
  • Plugin surface is separate. Hooks, commands, band, and board are outside this review.
  • Always-on posture can conflict with project rules. A repository with strict architectural conventions may need lite or a narrower scope.
  • No security method. "Never cut security" is a constraint, not a review procedure.

Verify it yourself

  1. Read the core SKILL.md and confirm it contains the ladder, the never-cut list, the test rule, and the end-of-reply disclosure.
  2. Decide whether you are installing the skill or the plugin. If the plugin, inspect the hooks and the band's storage path before trusting them.
  3. Run the skill on a small task with an obvious existing helper. Check whether it reuses the helper or invents a new abstraction.
  4. Ask for a feature with a deliberate non-goal. Check whether the reply names the non-goal and the risk.
  5. Do not repeat the README's benchmark percentages as your own result. If you want a number, run your own before/after measurement.

Review transparency

FieldValue
Last reviewed2026-10-23
What was inspectedFull skills/ponytail/SKILL.md, repository README sections on install, commands, band, how it works, and license, pinned commit metadata
What was not doneNo install, no plugin or hook execution, no benchmark run, no dashboard inspection, no model comparison
ReviewersEditorial source inspection only. Not a two-model security review.
Re-vet triggerAny change to the core skill; a plugin or hook change; more than 30 days

This is an original guide. It does not reproduce the full skill text, and it does not audit the plugin package.