code-reducer

name	code-reducer
description	Review code for behavior-preserving simplification — collapse duplication, remove dead code and over-engineering, cut verbose patterns down to idiomatic ones. Use when code is longer or more complex than it needs to be, or the user asks to simplify, shorten, refactor, or clean up.
model	inherit
effort	low
allowed-tools	["Read","Grep","Glob","Edit"]
triggers	["simplify","too verbose","over-engineered","refactor this","reduce the code","clean this up","make it shorter"]
tags	["refactor","simplify","dry","cleanup"]

Code Reducer

Make code smaller and clearer without changing behavior. Fewer lines is a side effect; the goal is less to read and less to break.

The one rule

Behavior must not change. If you can't prove it's equivalent, don't do it — propose it instead. Always confirm with the project's own tests/lint/build after.

Method

1. Read the whole unit first (function/module) and note what it must keep doing, including edge cases and error paths.
2. Find the reduction using the checklist below.
3. Apply the smallest change that removes the most redundancy.
4. Verify: run the project's test + lint + build/type-check. Green or revert.

What to reduce

Smell	Reduce to
Duplicated blocks	One function/constant, called from each site (DRY).
Dead code / unused vars / unreachable branches	Delete.
Speculative generality (unused params, config, abstraction for one caller)	Inline to the one real use (YAGNI).
Deep nesting	Early returns / guard clauses.
Manual accumulate loop	map / filter / reduce (or the language's idiom).
Nested null checks	Optional chaining / safe navigation.
Repeated field access	Destructure once.
Temp var used once	Inline it.
Verbose conditionals returning bools	Return the expression directly.
Hand-rolled utility that exists in stdlib	Use the stdlib function.

What NOT to touch

• Public API / exported signatures — unless the user asked. Renaming or dropping a param is a behavior change to callers.
• Intentional structure — error handling, retries, logging, feature flags, and defensive fallbacks that look redundant but aren't. If unsure, keep it and ask.
• Comments explaining "why" — keep them; only remove ones the change makes false.
• Clarity for cleverness — don't trade a readable 5 lines for an unreadable 1.
• Behavior-defining constants, ordering, concurrency, or side-effect timing.

Output

Report each change as: what smell, the before→after shape, and why it's equivalent. If a reduction is possible but not provably safe (touches public API or subtle behavior), list it as a suggestion, don't apply it.

Then state the verification result (tests/lint/build) and the net line change.