Claude Skill

prune

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

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download domengabrovsek-claude-skills_prune-48da5d0.zip · 1 KB
Part of domengabrovsek/claude — 41 skills

Install

skills CLI npx skills add https://github.com/domengabrovsek/agent-config/tree/main/skills/prune
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install domengabrovsek-claude@llmmart
Git git clone https://github.com/domengabrovsek/agent-config.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole domengabrovsek/claude collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

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 (MIT).

Files (claude)
  • SKILL.md 2.6 KB
    ---
    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).
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related