simplify

/simplify - the subtraction gate

The one question: what can go?

Every other gate asks whether the code is right, safe, worth keeping, or what he asked for. This one asks only whether the same behaviour could be expressed in fewer moving parts.

The headline is places-a-rule-lives, not line count. Line count is a proxy and it lies in one specific direction: collapsing three copies of a formatting rule into one documented helper plus three calls can END UP LONGER and still be the right call, because the rule can no longer drift between copies. Report the net delta always, but judge the pass on duplication killed and call sites collapsed. A net increase is acceptable ONLY when it buys a genuine collapse — a 50-line abstraction that removes two duplicates is the failure this rule exists to catch; a 14-line helper that removes nine duplicated expressions across three idioms is a pass.

Runs SELF-CONTAINED. Do not delegate to code-simplifier or feature-dev:code-reviewer — both plugins are disabled in settings.json, so a command that reaches for them reports a clean pass having done nothing. That is the exact failure this file was written after.

Where it sits

/verify     does it work?           <- REQUIRED FIRST. green baseline or stop
/thrift     is this the right way?  <- the approach changes before the shape does
/simplify   what can go?            <- YOU ARE HERE. subtract
/polish     is it finished?         <- then add: edge cases, empty states, error paths
/assay      is it worth keeping?    <- worth
/3pv        is it what he asked?    <- intent
ship

/finish runs the whole chain in order.

Largest blast radius first: approach → structure → edges → worth → intent. Subtract before you finish — an empty state written for a component that gets inlined gets written twice — and let thrift settle the mechanism before you spend effort shrinking one it is about to replace.

Not /cleanup. That one is whole-project maintenance — file organisation, stale docs, unused dependencies, lint, .env.example, vulnerable packages — and it ranges across the repo. This one touches only the current change set and only its code. They overlap on dead code alone; if the job is "tidy the project", it is /cleanup.