Skills dietrichgebert ponytail Ponytail
ponytail-review
- Use it when:
- You want a diff, branch, pull request or your last commit reviewed for what will actually break, not for style.
- It does:
- Reads the change and the code around it, such as callers, tests and the README, then checks correctness, safety, load, tests, speed and needless code, in that order.
- You get:
- Numbered plain-English findings under Must fix, Should fix and Nice to have, each with what the code does, the problem, the fix and the cost of skipping it.
- Ends with:
- A verdict, such as "Ship." or "fix 1 and 3 first", and how many lines could go.
- Unlike ponytail-audit:
- That one runs the same checks across a whole repo instead of one change.
- Won't:
- Change code, or report style taste or a finding without a concrete failing case.
Skill 2 of 5 in the Ponytail bundle, after ponytail and before ponytail-audit.
TL;DR
Ponytail is a skill set that makes coding agents write the least code that fully solves a task; this is its reviewer, modelled on the senior developer who gets paged when a change breaks. With no target named, it reviews uncommitted changes, or the last commit if there are none. It reads past the diff, to the callers of every changed function, the functions it calls, the tests and the README, and greps every caller when a signature or return value changes. It looks in the repo for the expected load, from one person running a script to many users at once, and says which it assumed. Findings rank by correct, safe, holds under load, tested, fast, lean: missed edge cases and broken callers, injection and data loss, races and a query per item, risky logic with no test, real slowdowns, and code to delete, reuse, merge or split. Each needs a concrete case that goes wrong, and a shortcut marked with a shortcut: comment naming its limit counts as a decision. Findings are numbered so you can say "fix 2 and 5", and written in short everyday sentences for a reader who's never seen the code.
Summarizes the skill at 96608e0.
npx skills add https://github.com/dietrichgebert/ponytail --skill ponytail-review skills.sh pageSource on GitHubAll skills from dietrichgebert/ponytail
- Total Downloads
- 67,187 on skills.sh, Nov 9, 2026
- Repo stars
- 187,013 dietrichgebert/ponytail
- First seen
- Jun 12, 2026 on skills.sh
Weekly values
| Week to | Installs |
|---|---|
| Sep 21 | 2,591 |
| Sep 28 | 2,486 |
| Oct 5 | 3,221 |
| Oct 12 | 8,440 |
| Oct 19 | 10,867 |
| Oct 26 | 6,013 |
| Nov 2 | 5,776 |
| Nov 9 | 4,529 |
| Category |
Find root causes, review code and test what you built. Everything for building software: planning, coding, debugging, design, frameworks, cloud, agents and skills. |
|---|---|
| Type |
A multi-step process the agent follows: interview, debug, run a TDD loop, review. |
| Effect |
Adds no side effects of its own. It shapes how the agent thinks, writes or reviews. Guidelines and routers are always effect:none, even when the task they support edits code. |
| Needs |
Instructions only. Works in any agent that supports skills. |
| Publisher |
Everyone else. Unverified vendor claims default to community. |
| Topics |
SKILL.md
From dietrichgebert/ponytail at 96608e0. Checked daily, last changed Nov 6, 2026.
Frontmatter
name: ponytail-review
description: >
Quality review of a change: is the logic right, is it safe, does it hold
under real load, is risky code tested, is it fast enough, and is every line
needed. Reads the connected code, not only the diff. Each finding is
explained in plain English. Use for "review this", "code review", "review
the last commit", "review my PR", "is this over-engineered", /ponytail-review.Review a change like the senior developer who will be paged when it breaks. Order of importance: correct, safe, holds under load, tested, fast, lean. Lean still matters: every extra line must be read, tested and fixed later. This is a report the user asked for, so give it in full.
1. Understand first
- Review what the user names: uncommitted or staged changes, a branch, a PR link, or files. Nothing named: the uncommitted changes, or the last commit if there are none.
- Read the diff, then the code it touches: callers of every changed function, the functions it calls, the tests, the README.
- Trace the real flow: where data comes in, what is stored, what goes out.
- A change can break code it does not touch. When a signature, return value or behavior changes, grep every caller.
- Find the expected load in the repo (README, deploy config): one person running a script, or many users and processes at once. Judge scale against that, and say which load you assumed.
2. Look for
- Bug: wrong result, crash, missed edge case (empty, zero, last item, rounding, time zones), a caller broken by the change, a fix applied in one caller while the shared function stays broken.
- Risk: security holes (injection, weak randomness, secrets, missing checks on input from users), data loss (errors swallowed, writes in the wrong order, no transaction).
- Scale: fine for one user, wrong for many: check-then-write races, the same work done by every process, memory or lists that only grow, a query per item, O(n^2) on big input, per-process state that must be shared.
- Missing test: risky new logic (a branch, a parser, money, security, data writes, a bug fix) with no test that fails when it breaks. One good test, not coverage.
- Speed: big slowdowns are problems. Small wins (work repeated in a hot loop) are suggestions; some software counts every millisecond.
- Lean: code that should not exist or should be smaller.
- delete: dead code, unused options, speculative features
- reuse: the repo already has this helper (name the path)
- stdlib / native: the standard library or platform already does it; a new dependency for a few lines
- yagni: abstraction with one implementation, config nobody sets
- merge: near-copies that must change together
- split: one function doing several unrelated jobs, so it is hard to read or test. Split by job, never by line count, and never into helpers that exist only to make a function shorter.
3. Check before you report
- Every finding needs a concrete case: "this input or situation leads to this wrong result". No case, no finding.
- Re-read the lines and confirm: the caller exists, the value can really be empty, the code really is unused.
- A shortcut marked with a
shortcut:(or olderponytail:) comment that names its limit is a decision, not a finding, unless the expected load already crosses it. - Propose the smallest fix that works. Prefer fixes that delete code. Never add layers, frameworks or config the problem does not need.
- No style taste, no "consider", no vague worries.
4. Output
Very simple English: short sentences, everyday words. Explain a technical term the first time you use it. The reader may never have seen this code.
Start with What this change does: in two or three sentences.
Then the findings in three groups, skip empty groups:
- Must fix: bug, security, data loss, breaks at the expected load.
- Should fix: risky code without a test, real slowness, duplication, a function that mixes jobs, code that should not exist.
- Nice to have: small speed-ups, shorter forms.
Number findings across all groups, so the user can say "fix 2 and 5". Every finding has all four parts, each one or two short sentences:
- Orders land on the wrong day (
billing/close_day.py:L40-52)- What this is: At midnight this job closes the day and bills all orders of that day.
- Problem: It takes "today" from the server clock, which runs in UTC. An order placed at 00:30 in Berlin is billed on the day before.
- Fix: Compute the day once in the shop's time zone:
datetime.now(ZoneInfo("Europe/Berlin")).date(). One line, nothing else changes. - If we skip it: Late orders show the wrong date, and accounting fixes them by hand.
End with:
Verdict: Ship.orVerdict: fix 1 and 3 first.Lean: -<N> lines possible.when lean findings exist.Not checked:one line, if something mattered and you could not check it.
Nothing found: What this change does:, then Looks good. Ship. and one line
on what you checked.
Lists findings, changes no code.