Prune

---
name: prune
description: "Reviews code exclusively for over-engineering and lists what to delete: reinvented standard library, unneeded dependencies, speculative abstractions, dead flexibility. Use when the user says 'review for over-engineering', 'is this over-engineered', or invokes /prune. Complements correctness-focused review; this one only hunts complexity."
---

If no diff is in context, fetch one first: run `git diff HEAD` for uncommitted
changes, `gh pr diff $ARGUMENTS` for a PR number, or `git diff main...HEAD`
for the current branch.

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

**why-no-hook:** scope and YAGNI exceptions are subjective complexity judgments; no hook can detect that a finding belongs in a "correctness" pass versus a "complexity" pass.

- Complexity only - correctness bugs, security holes, and performance go to a normal review pass, not this one `(review-time: see section note)`
- A single smoke test or `assert`-based self-check is the minimum, not bloat - never flag it for deletion `(review-time: see section note)`
- Does not apply the fixes, only lists them `(review-time: see section note)`

## Attribution

Adapted from [DietrichGebert/ponytail](https://github.com/DietrichGebert/ponytail) (MIT).