refactorlisted

# refactor — earn it first, then preserve behavior `/refactor` — survey the repo, emit a brief of where improvement pays off `/refactor <target or goal>` — execute one candidate, safely Answer one question: **where does structural improvement actually pay for itself in this codebase — and how is that change made without changing behavior?** The skill exists to prevent the two documented failure modes of "improve the architecture": refactoring the wrong code (most ugly code is never touched again, so cleaning it returns nothing), and **pattern-itis** — applying design patterns because they're best practices rather than because a problem here demands them, turning straight-line code into abstraction lasagna. ## Survey mode — `/refactor` ### Step 1 — Evidence, not aesthetics Candidates come from signals, never from "this code looks bad": - **Hotspots** — churn × complexity. Churn from git itself: `git log --format= --name-only --since="12 months ago" | sort | uniq -c | sort -rn | head -30`, crossed with a complexity proxy (file length, indentation depth). Code that is both complex *and* frequently edited is where interest compounds; complex-but-cold code is a LEAVE by default. - **The bug log** — `out/dev/bugfix-log.md` if present. A file that shows up repeatedly is structural debt announcing itself. - **Upcoming work** — the user's stated goals, open specs and plans under `out/dev/`. These seed **PREP** candidates: make the change easy, then make the easy ch