refactoringlisted

# Refactoring Improve code structure without changing behavior. One small step at a time. **Iron Law:** ONE REFACTORING → TEST → COMMIT. Never batch changes. ## When to Use Answer IN ORDER. Stop at first match: 1. User says "refactor", "clean up", "restructure"? → Use this skill 2. User asks to "extract", "rename", "simplify"? → Use this skill 3. Code smell identified? → Use this skill 4. User wants to add feature or fix bug? → Skip (use tdd-enforcer) 5. User wants formatting/style fixes? → Skip (use /lint) **Code smells** (common triggers): - Duplicated code (same logic in multiple places) - Long function (>30 lines, doing too much) - Magic numbers/strings (unexplained literals) - Deep nesting (>3 levels of indentation) - Dead code (unused functions, unreachable branches) - Poor naming (unclear what something does) --- ## Phase 1: ASSESS **Is this actually refactoring?** | User Intent | Action | | ------------------- | ----------------------------------------------- | | "Make this cleaner" | ✓ Refactoring | | "Add validation" | ✗ New behavior → tdd-enforcer | | "Fix this bug" | ✗ Bug fix → tdd-enforcer or systematic-debugger | | "Format this code" | ✗ Style → /lint | **If not refactoring:** Explain and suggest correct approach. --- ## Phase 2: PROTECT **Does the code have tests?** | Coverage | Action