refactor-planlisted

# Refactor Plan When this skill is activated, produce a `docs/REFACTOR_PLAN.md` that lays out how to refactor a piece of code *without changing its behavior*. The plan exists to make refactoring safe and reversible — not to redesign the system. Behavior changes belong in a separate, clearly-labelled effort. ## Clarifying Questions Before writing the plan, ask the engineer the following. Skip any already clearly answered in the conversation. **Wait for the answers before proceeding.** 1. What is the target — which module, class, or function is being refactored? 2. What is the goal of the refactor? (e.g. reduce coupling, extract a seam, remove duplication, split a large unit, improve naming) 3. What behavior must be preserved exactly? Are there observable contracts (APIs, outputs, side effects) that callers depend on? 4. What test coverage exists today for the target? Is it enough to detect a behavior change, or must characterization tests be written first? 5. Are there constraints — public APIs that cannot change, performance-sensitive paths, no new dependencies, a deadline? ## Steps 1. Read the target code and map its current behavior and dependencies. 2. Assess the safety net: if existing tests do not pin down current behavior, the first step of the plan is to add **characterization tests** that capture behavior as-is. 3. Break the refactor into the smallest reversible steps that each keep the system green (compiling and passing tests). 4. For each step, define the ver