prune

Prune

Agents add code more readily than they remove it. Each session solves its task locally: it writes a helper instead of finding the existing one, guards against failures that cannot happen, keeps the old path "just in case", and narrates the change in a comment. When the architecture gives code no obvious home, the same concept gets rebuilt in every corner. Over time, the project accumulates more code, concepts, and dependencies than its behavior needs.

This skill fights that entropy in periodic passes, from removing a dead function up to restructuring modules. The goal is a net reduction in what a reader must understand — fewer lines, files, concepts, and dependencies — with behavior unchanged except where the user explicitly agrees to remove a feature. Making code merely prettier is not the goal. A change that adds structure must pay for itself with measurable reduction: concepts merged, duplicates eliminated, dependency rules that stop a smell from recurring.

The skill operates on the current working tree and branch as it finds them. It does not create branches or worktrees; isolation is the caller's responsibility.

Scope

By default, every run surveys the whole project and considers every class of change. The user does not need to pass anything.

Narrow the run only when the user asks for it in their own words, e.g. "only src/server", "just what changed since last time", "only the safe stuff, don't ask me". Map such requests onto the knobs below and state the resulting scope at the start of the run:

• Paths — survey only the given paths. Candidates are still checked against the whole repository for duplicates and references.
• Since last run — survey only files changed since the most recent run record's end commit. If that commit is not an ancestor of HEAD, fall back to the record's date with git log --since and note the fallback.
• Mechanical only — execute mechanical items without the confirmation stop; record everything else as deferred.