refactoringlisted

## Context marker 📐 When the skill activates, begin the first commentary update with `📐` and a concise `Using refactoring ...` announcement. Do not repeat the marker on later updates unless another skill activates. # Refactoring: Designing Your Code Refactoring is how you design your code. It is not cleanup after the fact — it is an active design activity that shapes the code into a clear expression of its intent. Work autonomously as much as possible. Start with the simplest thing or file and proceed to the more complex ones. ## Stages 1. Prep 2. Main Refactoring 3. Final Evaluation 4. Summary ## Specification Code Policy Do not change specification code during refactoring, except: - Renames that follow production code renames (imports, function calls) - Import path updates if something moved Never change specification assertions, specification data, or specification logic. ## 1. Prep - Determine scope: use specified files, or identify related files (imports, shared functionality), or ask user - Add files in scope to todo list - Find or create ./spec.sh, verify all specs pass - Review comments in scope; preserve required documentation, safety notes, licenses, and useful rationale, and remove only comments made redundant by clearer code ## 2. Main Refactoring ### Code Style Prefer self-explanatory, readable code over comments. - Use functional helper methods for clarity - Remove dead code - Extract paragraphs into methods - Use better variable names - Remove