---
name: Ponytail Review
slug: ponytail-review-2
category: Quality
description: "Ponytail Review reviews a code diff for over-engineering and flags what to delete: reinvented standard library functions, needless dependencies, speculative abstractions, and verbose code. Use it to keep changes lean and minimal."
github: "https://github.com/DietrichGebert/ponytail/tree/main/.openclaw/skills/ponytail-review"
language: JavaScript
stars: 101674
forks: 5587
install: "npx degit https://github.com/DietrichGebert/ponytail/tree/main/.openclaw/skills/ponytail-review ~/.claude/skills/ponytail-review"
installs_to: ~/.claude/skills/ponytail-review
source_path: .openclaw/skills/ponytail-review/SKILL.md
collection_size: 13
category_size: 1354
collection_url: "https://dirskills.com/collections/DietrichGebert/ponytail"
added: 2026-08-13T07:35:46.191Z
last_synced: 2026-08-13T07:35:46.191Z
canonical_url: "https://dirskills.com/skills/ponytail-review-2"
---

# Ponytail Review

Ponytail Review reviews a code diff for over-engineering and flags what to delete: reinvented standard library functions, needless dependencies, speculative abstractions, and verbose code. Use it to keep changes lean and minimal.

**Install:**

```bash
npx degit https://github.com/DietrichGebert/ponytail/tree/main/.openclaw/skills/ponytail-review ~/.claude/skills/ponytail-review
```

## README

Review diffs for unnecessary complexity. One line per finding: location, what
to cut, what replaces it. The diff's best outcome is getting shorter.

## Format

`L<line>: <tag> <what>. <replacement>.`, or `<file>:L<line>: ...` for
multi-file diffs.

Tags:

- `delete:` dead code, unused flexibility, speculative feature. Replacement: nothing.
- `stdlib:` hand-rolled thing the standard library ships. Name the function.
- `native:` dependency or code doing what the platform already does. Name the feature.
- `yagni:` abstraction with one implementation, config nobody sets, layer with one caller.
- `shrink:` same logic, fewer lines. Show the shorter form.

## Examples

❌ "This EmailValidator class might be more complex than necessary, have you
considered whether all these validation rules are needed at this stage?"

✅ `L12-38: stdlib: 27-line validator class. "@" in email, 1 line, real validation is the confirmation mail.`

✅ `L4: native: moment.js imported for one format call. Intl.DateTimeFormat, 0 deps.`

✅ `repo.py:L88: yagni: AbstractRepository with one implementation. Inline it until a second one exists.`

✅ `L52-71: delete: retry wrapper around an idempotent local call. Nothing replaces it.`

✅ `L30-44: shrink: manual loop builds dict. dict(zip(keys, values)), 1 line.`

## Scoring

End with the only metric that matters: `net: -<N> lines possible.`

If there is nothing to cut, say `Lean already. Ship.` and stop.

## Boundaries

Scope: over-engineering and complexity only. Correctness bugs, security holes,
and performance are explicitly out of scope. Route them to a normal review
pass, not this one. A single smoke test or `assert`-based
self-check is the ponytail minimum, not bloat, never flag it for deletion.
Does not apply the fixes, only lists them.
"stop ponytail-review" or "normal mode": revert to verbose review style.