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":