simplify

name

simplify

description

Harvest and apply code simplifications on recently-changed (or named) code — dead code, reinvented stdlib/builtins, premature generality, verbose patterns, and AI-slop filler — each tagged by category, with a single MEASURED `net: -N lines` score (the real post-apply diff delta, never a projected estimate). Use when the user says "simplify this", "deslop", "anti-slop", "trim the fat", "this is over-engineered", or "shrink this". Behavior-preserving by contract — verify tests before and after.

anti-hall:simplify

Find the smallest faithful version of code that already works. This is a harvest-then-prove pass, not a rewrite: every simplification must preserve observable behavior, and the only score that ships is the actually-measured line delta — never a guess about what you "would" save.

Behavior-preserving by contract. Simplification removes redundancy, not capability. Deleting a feature, a branch that real callers hit, or an edge-case guard is NOT a simplification — it's a scope change. If you're unsure whether something is load-bearing, it stays. (Scope-fidelity is an Iron-Law corollary: do exactly the task, no less.)

Scope

Default target = the code changed in this session (or the current diff / staged set). The user can name a file, directory, or function instead. Never sweep the whole repo unprompted — that's a different, much riskier job and invites incidental behavior changes.

The tag taxonomy

Every finding gets exactly one tag — the dominant reason it can shrink:

Tag	Means	Typical fix
delete:	Dead / unreachable code, unused vars/imports/params, commented-out blocks, branches no caller reaches	Remove it
stdlib:	Hand-rolled logic the standard library already provides	Call the stdlib function
native:	A language builtin / idiom reimplemented by hand (e.g. manual loop where a map/filter/spread fits)	Use the builtin
yagni:	Premature generality — config, flags, abstraction layers, or hooks with no current caller	Inline to the one real use; delete the speculative seams
shrink:	Correct but verbose — a shorter equivalent says the same thing as clearly	Tighten (but never at the cost of readability)
slop:	AI-slop filler — redundant comments restating the code, defensive checks for impossible states, ceremonial boilerplate, needless intermediate vars	Strip the noise

Ambiguous between two tags → pick the one that explains the most removed lines. shrink: and slop: are the "judgment" tags — only apply them when the result is genuinely clearer, never just shorter. Clever-but-cryptic is a regression, not a simplification.

Workflow

1. Baseline must be green first. Run the relevant tests/build and confirm they pass before touching anything. You cannot prove behavior was preserved against an already-broken baseline. Record the starting line count of the target (wc -l, or git diff --stat if working a diff).
2. Harvest. Read the target and list findings as TAG file:line — what & why plus the concrete before→after. Don't apply yet; assemble the full list so duplicates and interactions are visible (one change can subsume another).
3. Apply the safe set. Make the edits. Skip anything that trades clarity for brevity or that you can't prove is behavior-neutral — note those as declined with the reason.
4. Prove it. Re-run the SAME tests/build. They must still pass. If anything goes red, revert that finding — a simplification that breaks a test was a behavior change in disguise.
5. Score — measured only. Report net: -N lines where N is the real delta from git diff --shortstat (or before/after wc -l) after the edits are applied and tests are green. This is a fact, not a forecast.

The score is a measurement, not a sales pitch

net: -N lines is legitimate only because it's the observed diff of work that actually landed and still passes its tests. Never print a "you'll save ~X lines" number for un-applied changes, and never inflate the figure with declined or speculative findings — that's exactly the kind of unverifiable saved-X claim the verify-first protocol forbids (rule 10). If nothing safely shrank, the honest score is net: 0 lines and that's a fine outcome.

Output shape

simplify: <target>   (baseline: <L0> lines, tests: green)

delete:  path/x.js:42      removed unused `tmp` + dead else-branch        (-6)
stdlib:  path/y.js:13      replaced manual dedupe with [...new Set()]      (-4)
yagni:   path/z.js:88      inlined single-caller `makeOpts()` wrapper      (-9)
slop:    path/x.js:7       dropped comment restating the next line         (-1)

declined:
  shrink: path/y.js:60 — one-liner would hurt readability; kept

net: -20 lines   ·   tests: green (re-run, 0 fail)   ·   behavior: unchanged

Honest boundaries

• Not a reformatter / linter. Whitespace and pure style churn belong to the formatter, not here. slop: is about semantic noise (redundant logic/comments), not trailing spaces.
• Not a refactor. Renaming for clarity, splitting modules, or changing public signatures is out of scope — those change interfaces and need their own review.
• One-way door check. If a finding deletes the only path that exercised some capability, it's a capability removal — surface it as a question, don't silently apply it.