simplifylisted

# Code Simplification Simplify code by reducing complexity while preserving exact behavior. The goal is not fewer lines — it's code that is easier to read, understand, modify, and debug. Every simplification must pass one test: "Would a new team member understand this faster than the original?" ## When to use - After a feature works and tests pass, but the implementation feels heavier than it needs to be - During code review when readability or complexity issues are flagged - When you encounter deeply nested logic, long functions, or unclear names - After merging changes that introduced duplication or inconsistency - Triggers on "simplify", "too complex", "refactor for clarity" **Not for:** code you don't fully understand yet — comprehend before you simplify. Performance-critical code where the "simpler" version would be measurably slower. Throwaway code about to be rewritten entirely. Cross-module structural changes — extracting/moving modules, redrawing dependency boundaries, splitting or merging files → use `refactoring`. Designing where a seam or deep module should go (producing an audit, not executing) → use `codebase-design`. Single-file clarity stays here: naming, nesting, dead code. ## Steps ### 1. Understand before touching (Chesterton's Fence) Before changing or removing anything, understand why it exists. If you see a fence across a road and don't understand why it's there, don't tear it down. - What is this code's responsibility? What calls it, what does i