simplify-codelisted

# Simplify Code Simplify-phase skill — cross-phase, usable during Build (refactor intent) or as standalone cleanup. Cut complexity that does not earn its keep. Behavior-preserving — every change is provable by the existing tests. ## Iron Rule <EXTREMELY-IMPORTANT> 1. NEVER simplify without a test suite that proves behavior before and after. 2. NEVER remove an abstraction the codebase actually depends on — verify call sites first. 3. NEVER add a new abstraction for "hypothetical future use". One concrete user is not enough. 4. Same pattern in 3+ places → centralize. On the high-risk list — auth, billing, credits, URL validation, redirects, SSRF, cookies, logging, retries, external API — TWO occurrences already force it. 5. Apply the deletion test before any cut. Imagine deleting the module: if complexity vanishes, it was a pass-through — delete safely. If complexity reappears scattered across N callers, the abstraction was earning its keep — keep it. </EXTREMELY-IMPORTANT> ## When to use - Code reviewer flagged over-engineering or duplication - A file is > 500 lines and looks like it grew by accretion - An abstraction has exactly one caller - A defensive null-check / try-catch covers an "impossible" case - Same logic copy-pasted in 3+ files - User says "this is getting messy" or "refactor X" Skip when: - Tests don't exist for the touched code — write them first via `implement-plan` or `debug-issue` - The "complexity" is load-bearing (security boundary, data invariant) -