refactoring-guidelisted

# Refactoring Guide ## Core Rule Recommend Fowler-named refactors only when current behavior is understood and tested. Apply stepwise; verify between each step. ## When to Use Invoke with `/refactoring-guide` when: - Code smells have been identified and need systematic fixes - A module has grown unwieldy and needs restructuring - Preparing for a feature that requires cleaner foundations - After a `/code-quality-audit` to get actionable refactoring steps - Technical debt needs to be paid down incrementally ## Process ### Phase 1: Assess Current State 1. Read the target code thoroughly — understand what it does before changing how it does it 2. Identify existing tests — refactoring without tests is dangerous 3. Map dependencies — what depends on this code? What does it depend on? 4. Check for active development — avoid refactoring code with open PRs or in-progress features ### Phase 2: Identify Refactoring Opportunities Map code smells to Fowler's refactoring catalog: **Extract Techniques** (breaking things apart) | Smell | Refactoring | When | |-------|-------------|------| | Long function | Extract Function | Function >30 lines or does multiple things | | Large class | Extract Class | Class has multiple distinct responsibilities | | Feature envy | Move Function | Method uses another object's data more than its own | | Data clumps | Introduce Parameter Object | Same group of parameters passed together | | Primitive obsession | Replace Primitive with Object | Primiti