refactorlisted

# Refactor Improve code structure without changing behavior. Works at three scopes: **project**, **file**, or **method**. Starts by assessing whether refactoring is even warranted — if the code is already clean, say so and stop. **Refactoring vs Architecture:** This skill handles code-level improvements — complexity, duplication, naming, dead code, method extraction. If the assessment reveals that the real problem is module boundaries, coupling between packages, or shallow modules that need deepening, say so — that's an architecture problem this skill won't fix (suggest the `improve-architecture` skill if installed). ## Philosophy These principles calibrate what "good enough" means and guide every step below: - **Measure the end state, not the effort.** Writing 50 lines that delete 200 is a win. - **Simple over easy.** Simple means one concept, not intertwined. Easy means familiar. Choose simple. - **Separate, don't combine.** Good design is taking things apart — removing dependencies, not adding abstractions. - **Data over abstractions.** 100 functions on one data structure beat 10 functions on 10 custom types. - **Less total code.** If "better organized" means more lines, it's more entropy, not less. - **When in doubt, leave it alone.** The default verdict is Clean. Don't invent work. See `references/` for deeper exploration of these ideas. ## Step 1: Determine Scope Infer from the user's request: | Trigger | Scope | |---------|-------| | "refactor this method/func