Ponytail Claude skills

Using Ponytail day to day: modes and the decision ladder

The main skill stays active for the whole session once it loads. Run /ponytail lite, /ponytail full or /ponytail ultra to change how strict it is. To turn it off without uninstalling, tell the agent "stop ponytail" or "normal mode".

What the agent writes comes from a six-step ladder. It takes the first option that fully solves the task:

1. Skip anything nobody asked for, and name what was skipped in one line. A vague request like "build me X" gets the smallest version that does the core job.
2. Reuse a helper, component, service or pattern already in the codebase, the same way the surrounding code uses it.
3. Use the standard library or a native platform feature, unless the project has its own version. A house component beats a native widget.
4. Use a dependency that is already installed. Never add one for a few lines.
5. Write one line a reader understands at a glance.
6. Otherwise, write the minimum code that works.

A few rules come up often in real work. For a bug fix, the agent greps every caller of the function before editing and fixes the root cause once, in the shared code. Code it moves or merges keeps its error handling and validation. If two options are the same size, it picks the one that handles edge cases correctly. Comments explain only the why. The skill treats unrequested options, config, wrappers and "for later" code as out of scope, so if you want one of those, ask for it in the prompt.

Tracking deliberate shortcuts with ponytail-debt

When Ponytail takes a deliberate shortcut, it marks the spot with a shortcut: comment that names the ceiling and the upgrade path. Older code may use ponytail: instead. ponytail-debt collects these markers into one ledger so a deferral gets tracked instead of becoming permanent by accident.

The skill greps the repo and skips .git and anything your .gitignore files exclude:

git grep --no-index --exclude-standard -nE '(#|//|/[*]) ?(shortcut|ponytail):'

To track your own marker word, pass it in, for example /ponytail-debt TODO. Each hit becomes one row, grouped by file, in the form <file>:<line>, <what was simplified>. ceiling: <the limit named>. upgrade: <the trigger to revisit>. A marker with no upgrade path or trigger gets a no-trigger tag, since those are the ones most likely to rot. The report ends with a count of markers and how many have no trigger.

The skill only reads and reports. If you want the ledger saved, ask and it writes it to a file such as PONYTAIL-DEBT.md. You can also add git blame to put an owner on each row.

What ponytail-audit checks, and in what order

ponytail-audit covers whatever you name: a folder, a package or the whole repo. If you don't name anything, it audits the whole repo. It maps the project before judging it. That means reading the README, deploy and build config, dependency list, entry points (routes, handlers, jobs, CLI commands) and tests, then tracing the main flows end to end. It also works out the expected load, from one person running a script to many concurrent users, and states which load it assumed.

Findings are ranked in this order: correct, safe, holds under load, tested, fast, lean. Bugs include missed edge cases such as empty input, zero, time zones and rounding. Risk covers injection, weak randomness, secrets in code and swallowed errors. Scale looks for check-then-write races, a query per item and lists that only grow. Missing tests means risky logic with no test that fails when it breaks. Lean flags dead code, duplicate helpers and anything the standard library already does. In a large repo it goes deep where mistakes cost the most and lists the parts it did not read.