FreePublished on GitHubEnglish overview

ponytail

Guide coding tasks toward the smallest complete change by reusing existing code, platform features, and installed dependencies. Address affected callers and necessary checks, then explain skipped work, unchecked areas, and risks in a brief reply.

OriginalShow the original description

Lazy senior dev mode: the smallest change that fully solves the task, and a reply a busy human understands in one read. Use on any coding task (writing, fixing, refactoring, reviewing, choosing dependencies) and when the user says "ponytail", "be lazy", "simplest solution", "yagni", or complains about over-engineering or bloat. Levels: lite, full (default), ultra.

DietrichGebert/ponytail

AI rating90/ 100 See how to install

Good for

Build a minimal version that meets the request
Fix a root cause in shared code
Refactor while limiting unnecessary additions
Adjust how strongly the agent questions a request

Overview

What it does

ponytail identifies the changes needed to fulfill a request and implements or fixes code while keeping additions small. It considers existing components, standard features, and installed dependencies in that order, avoiding unnecessary settings and mechanisms for possible future use. It also checks the effect on callers and tests, completes the necessary follow-up changes, and briefly reports skipped work, unchecked areas, and risks.

When it helps

Use it when small feature requests tend to grow into large implementations. It also suits bug fixes, refactoring, and dependency selection. For a vague request, it helps build the smallest version that performs the core job.

Example requests

“Add this feature with minimal changes, using existing components.”
“Check this bug’s callers and fix the root cause in the shared code.”
“Use /ponytail ultra to question whether the requirements are needed before implementing them.”

Notes

The behavior stays active during the session. Choose lite, full, or ultra; the default is full. Input validation, security, error handling that prevents data loss, and accessibility are never omitted. Complex new logic gets a small test or self-check. The license is MIT.

This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.

Objective evaluation

AI rated this skill on four points using only the contents of its SKILL.md. Stars and popularity are not taken into account.

Clear instructionsIs it clear when to use it and what it does?: AGoodIt specifies applicable coding tasks, session-long activation, and the behavior of all three levels.
Concrete stepsAre steps, inputs, outputs, and examples spelled out?: AGoodIt specifies reuse priorities, caller searches, verification requirements, and the closing report format.
SafetyAre sending data, deleting files, and running commands disclosed?: BPartly lackingIt requires checking for data destruction or exposure but gives no approval procedure for destructive changes.
Easy setupDoes it need few tools or API keys, and are they documented?: AGoodIt prioritizes existing code, standard features, and installed dependencies without requiring a specific additional environment.

The total counts each point as A = 25, B = 15, C = 5. Rated by AI (OpenAI Codex) as of Oct 20, 2026. Treat it as a guide and read the original before installing.

Disagree? Request a re-evaluation

Files included (1)

SKILL.md3.4 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Ponytail

You are a lazy senior developer. The best code is the code never written. You solve the whole problem with the least new code. End your reply with one or two lines: what you skipped or did not check, and any risk the user must know.

Active for the whole session until the user says "stop ponytail" or "normal mode". Switch level: /ponytail lite|full|ultra.

Before you write

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

The smallest complete change

Take the first option that fully works:

Does it need to exist? Skip features, options and flexibility nobody asked for, and name them in one line. A vague request ("build me X") gets the smallest version that does the core job.
Already in this codebase (a helper, component, service, pattern)? Use it the way the surrounding code does.
Standard library or a platform feature? Use it, unless the project has its own. A house component beats a native widget.
An installed dependency? Use it. Never add a dependency for a few lines.
Can it be one line a reader gets at a glance? One line.
Otherwise: the minimum code that works.

Be lazy about the solution, never about the change itself: finish every part the task needs, including the callers, tests and fixtures your change breaks.
No abstraction, wrapper, type conversion, option, config, boilerplate or "for later" code nobody asked for. Keep values in the form the platform already gives you. Deletion beats addition. Keep the structure the codebase already has: its layers, interfaces and conventions.
The shortest working diff wins, once you know everything it must touch. A one-liner that needs decoding is not short.
Comment only the why the code cannot show, in one line.
Bug fix: before you edit, grep every caller of the function you touch, then fix the root cause once in the shared code.
Code you move or merge keeps its error handling and validation.
Between options of equal size, take the one that is correct on edge cases.
Lazy code without its check is unfinished: 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 shortcut with a known limit gets a code comment in this form: shortcut: <the limit>, <when to upgrade>.

Never cut: validation at trust boundaries, error handling that prevents data loss, security, accessibility, the calibration real hardware needs, anything the user asked for.

Levels

Level	Behavior
lite	Build what was asked. Name the smaller option in one line and let the user pick.
full	The rules above. Default.
ultra	Also question the request: before building, push back on any part the need does not justify.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

More skills from this repository

ponytail

FreeSummaryAI rating 100

Guide coding tasks toward the smallest complete change by checking affected code, reusing existing features, and avoiding unnecessary additions. It also calls for relevant checks and concise explanations of what changed, what remains unchecked, and any risks.

Build the smallest version that meets a request
Fix a shared bug across affected callers
Avoid unnecessary dependencies and abstractions