New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Over-Engineering Review

by DietrichGebert in DietrichGebert/ponytail

Reviews a diff only for unnecessary complexity and lists what to delete or shrink, one numbered line per finding with the location, the cut and its replacement.

MITAuto-check passedDevelopment

Install Over-Engineering Review

skills CLI
$ npx skills add DietrichGebert/ponytail --skill ponytail-review -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install DietrichGebert/ponytail ponytail-review --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/DietrichGebert/ponytail.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/ponytail-review .claude/skills/ponytail-review && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
ponytail-review
GitHub stars
160k
Token cost
~1.3k tokens
SKILL.md length
760 words
Files
1
Skills in repo
6
Repo updated
First seen
Licence
MIT

At a glance

Reviews a diff only for unnecessary complexity and lists what to delete or shrink, one numbered line per finding with the location, the cut and its replacement.

  • Works in 4 steps: Understand first → Look for → Check before you report → …
  • Reviewing a pull request for over-engineering before merge
  • SKILL.md covers 1. Understand first, 2. Look for, 3. Check before you report and 4. Output
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

This review ignores correctness, security and performance and hunts only complexity. Each finding is one numbered line giving the location, what to cut and what replaces it, with numbering continuing across files so you can reply with something like "fix 2 and 5". Findings carry one of six tags: delete (dead code or speculative features), stdlib (hand-rolled code the standard library already ships), native (a dependency doing what the platform already does), reuse (a helper that already exists in the repo), yagni (an abstraction with one implementation, or config nobody sets) and shrink (the same logic in fewer lines).

The report ends with a net count of lines that could go, or says the code is already lean when there is nothing to cut. Vague remarks that only ask whether rules are needed are replaced by concrete cuts, like swapping a validator class for a one-line check or a date library for the built-in formatter. A single smoke test or assert-based self-check is treated as the minimum, never as bloat. The skill only lists changes and does not apply them, and "stop ponytail-review" or "normal mode" returns to a verbose style.

When your agent uses it

  • Reviewing a pull request for over-engineering before merge
  • Asking what can be deleted from a module
  • Spotting dependencies that duplicate built-in features

Example prompts

  • “Review this diff for over-engineering and tell me what we can delete.”
  • “Is this retry wrapper over-engineered? Give me the findings in the ponytail format.”
  • “/ponytail-review on the changes in src/payments.”

Workflow steps

4 steps, taken from the step headings in SKILL.md.

  1. Understand first
  2. Look for
  3. Check before you report
  4. Output

What it can do on your machine

Read from SKILL.md and the folder at commit 9b58c1f. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Over-Engineering Review loads about 1.3k tokens when it runs. Until then it costs about 97 tokens; SKILL.md has 760 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~97
When it runs · the whole SKILL.md, loaded when a task matches
~1.3k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from DietrichGebert/ponytail at commit 9b58c1f, republished under its MIT licence (© DietrichGebert). 760 words, ~1,286 tokens.

Download SKILL.mdSave it as .claude/skills/ponytail-review/SKILL.md (or your agent's skills folder).
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

  1. 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.
  2. Risk: security holes (injection, weak randomness, secrets, missing checks on input from users), data loss (errors swallowed, writes in the wrong order, no transaction).
  3. 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.
  4. 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.
  5. Speed: big slowdowns are problems. Small wins (work repeated in a hot loop) are suggestions; some software counts every millisecond.
  6. 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.
Show full SKILL.md (347 more words)Show less

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 older ponytail:) 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:

  1. 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. or Verdict: 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.

© DietrichGebert, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/ponytail-review of DietrichGebert/ponytail.

Open the folder on GitHubat commit 9b58c1f

Compare with similar skills

Over-Engineering Review next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Over-Engineering Review compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Over-Engineering Review this skillDietrichGebert/ponytail160k—~1.3kAutomated safety check: PassMIT
SimplifySeifBenayed/cloclo114—~430Automated safety check: NotesMIT
Review And Simplify ChangesDimillian/Skills4k—~2kAutomated safety check: PassMIT
Simplify Codetobihagemann/turbo408—~3.5kAutomated safety check: PassMIT
PonytailDavidObando/gsharp5657 repos~1.7kAutomated safety check: PassMIT
Dignified Python Standardsdocling-project/docling69k—~1.5kAutomated safety check: PassApache-2.0

Similar skills

  • Simplify

    SeifBenayed/cloclo

    Review code for unnecessary complexity and simplify it. An agent skill from SeifBenayed/cloclo.

    114 GitHub stars~430 tokensUpdated 6 mo ago
    DevelopmentAuto-check: notes

  • Review And Simplify Changes

    Dimillian/Skills

    Review a git diff or explicit file scope for reuse, code quality, efficiency, clarity, and standards issues, then optionally apply safe Codex-driven fixes.

    4k GitHub stars~2k tokensUpdated 6 mo ago
    DevelopmentAuto-check passed

  • Simplify Code

    tobihagemann/turbo

    Run a multi-agent review of changed files for scope, reuse, quality, efficiency, clarity, and altitude issues followed by fixes.

    408 GitHub stars~3.5k tokensUpdated 2 days ago
    DevelopmentAuto-check passed

  • Ponytail

    DavidObando/gsharp

    Forces the laziest solution that actually works, simplest, shortest, most minimal.

    565 GitHub starsUsed in 7 repos~1.7k tokens
    DevelopmentAuto-check passed

  • Dignified Python Standards

    docling-project/docling

    Applies opinionated production Python conventions chosen by the project's Python version: modern type syntax, pathlib, explicit checks and interface guidance.

    69k GitHub stars~1.5k tokensUpdated today
    DevelopmentAuto-check passed

  • Code Simplification for ego-lite

    citrolabs/ego-lite

    Finds and implements evidence-backed simplifications in the ego-lite repository, such as dead code, duplicated state and speculative abstractions, without hiding behavior changes.

    17k GitHub stars~1.2k tokensUpdated yesterday
    DevelopmentAuto-check passed

More from DietrichGebert/ponytail

  • Ponytail Gain Scoreboard

    DietrichGebert/ponytail

    Show ponytail's measured savings (code, cost, speed) from the benchmark. One-shot display. Use for /ponytail-gain, "what does ponytail save", "ponytail impact".

    160k GitHub stars~507 tokensUpdated yesterday
    Auto-check passed

  • Ponytail Lazy Developer Mode

    DietrichGebert/ponytail

    Makes the agent pick the laziest solution that works: skip unneeded work, reuse what exists, prefer the standard library and platform features, and keep diffs small.

    160k GitHub starsUsed in 1 repo~873 tokens
    Auto-check passed

  • Ponytail Help Card

    DietrichGebert/ponytail

    Shows a one-shot quick-reference card for the ponytail skills: intensity levels, the six commands, and how to turn it off, set a default mode and update.

    160k GitHub stars~726 tokensUpdated yesterday
    Auto-check passed

  • Ponytail Audit

    DietrichGebert/ponytail

    Quality audit of a whole repo: bugs, security holes, what breaks under real load, risky code without tests, slow paths, and what to delete, merge or split.

    160k GitHub stars~1.4k tokensUpdated yesterday
    Auto-check passed

  • Ponytail Debt Ledger

    DietrichGebert/ponytail

    Collects every ponytail: comment in a codebase into one debt ledger, flags shortcuts with no upgrade trigger and reports without changing any files.

    160k GitHub stars~453 tokensUpdated yesterday
    Auto-check passed

Categories

Questions about Over-Engineering Review

What does Over-Engineering Review do?

Reviews a diff only for unnecessary complexity and lists what to delete or shrink, one numbered line per finding with the location, the cut and its replacement. This review ignores correctness, security and performance and hunts only complexity. Each finding is one numbered line giving the location, what to cut and what replaces it, with numbering continuing across files so you can reply with something like "fix 2 and 5".

When should I use Over-Engineering Review?

Over-Engineering Review fits situations like: reviewing a pull request for over-engineering before merge; asking what can be deleted from a module; spotting dependencies that duplicate built-in features.

How do I install Over-Engineering Review in Claude Code?

Run `npx skills add DietrichGebert/ponytail --skill ponytail-review -a claude-code`. Or copy the skill folder (skills/ponytail-review in DietrichGebert/ponytail) into .claude/skills/ponytail-review in your project. Claude Code loads it when a task matches its description.

How do I install Over-Engineering Review in Codex?

Run `npx skills add DietrichGebert/ponytail --skill ponytail-review -a codex`. Or copy the skill folder (skills/ponytail-review in DietrichGebert/ponytail) into .agents/skills/ponytail-review in your project. Codex loads it when a task matches its description.

Can I use Over-Engineering Review in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add DietrichGebert/ponytail --skill ponytail-review -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/ponytail-review, .gemini/skills/ponytail-review, .github/skills/ponytail-review and .opencode/skills/ponytail-review in your project.

What does Over-Engineering Review need to run?

SKILL.md names no scripts, command-line tools or credentials: Over-Engineering Review is instructions for the agent only.

Does Over-Engineering Review access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Over-Engineering Review safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Over-Engineering Review use?

Over-Engineering Review is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Over-Engineering Review use?

About 1.3k tokens (SKILL.md is roughly 5.1k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Over-Engineering Review?

Skills that share tags, products or a category with Over-Engineering Review: Simplify (SeifBenayed/cloclo, 114 stars), Review And Simplify Changes (Dimillian/Skills, 4k stars), Simplify Code (tobihagemann/turbo, 408 stars) and Ponytail (DavidObando/gsharp, 565 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Over-Engineering Review?

DietrichGebert (a GitHub user) maintains it in DietrichGebert/ponytail, which has 159,864 GitHub stars. The repository holds 6 skills in this directory. The repository was last updated on October 10, 2026.

Source: DietrichGebert/ponytail on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.