loom-refactoring

# Refactoring ## Overview Change the internal structure of code without changing its observable behavior. Restructuring and behavior change are two different activities — never do both in one commit. ## The cardinal rule **Behavior-preserving, tests green before AND after.** If you can't prove behavior is unchanged, you're not refactoring — you're rewriting, and you need different discipline (characterization tests, feature flags; see `/loom-code-migration`). Corollaries an expert never violates: 1. **Tests are the safety net.** Run them before you touch anything (establish green). If there are none for the code you're changing, write **characterization tests** first (below) — do not refactor untested legacy blind. 2. **Tiny reversible steps.** One mechanical move at a time; re-run tests after each. When something breaks you know exactly which step did it and can `git checkout` a single step, not an hour of work. 3. **Separate refactor commits from behavior-change commits.** A `refactor:` commit must be a no-op at runtime — reviewers can trust the diff without re-verifying logic. Mixing a bug fix into a rename hides the fix and poisons `git bisect`. (Commit mechanics: `/loom-git-workflow`.) 4. **Don't change tests and production code in the same step.** If a refactor "requires" editing a test's assertions, behavior changed — stop and reconsider. ## Not this skill - Fixing a bug → `/loom-debugging` (that *is* a behavior change; write the failing test first). - Adding a...