refactoringlisted

# Refactoring Change structure without changing behavior. Prove it at every step. ## Why This Exists Refactoring feels safe — "I'm just moving things around." That's exactly why it's dangerous. Without a behavior lock, structural changes silently break contracts, reorder side effects, or drop edge cases. This skill enforces the discipline that makes refactoring actually safe. ## Phase 1: Behavior Lock Before touching any structure, lock the current behavior with tests. 1. **Run the existing test suite.** Detect the project's test runner (check `package.json` scripts, `Makefile`, `pytest.ini`, `Cargo.toml`, etc.) and run it. Every test must pass. If tests fail before you start, you're debugging, not refactoring — switch to `systematic-debugging`. 2. **Identify the refactoring surface** — which functions, modules, or files will be structurally changed. 3. **Audit test coverage on that surface.** For each function/module in scope: - Is there a test that exercises its public API or observable behavior? - If yes: verify it passes. That test is now your behavior lock. - If no: write a characterization test that captures current behavior. This test doesn't assert "correct" behavior — it asserts "current" behavior. The point is to detect unintended changes, not to validate design. **Writing characterization tests:** Call the function with representative inputs and assert on the exact output. For side-effectful code (writes files, sends requests, modifies state