TypeScript Refactoring

Refactoring is changing structure without changing behavior. Assess before changing. Small steps, verified continuously. The typescript skill defines what good TypeScript looks like — this skill defines how to get there from messy code.

1. The Iron Rules

These are non-negotiable. Violating them turns refactoring into "changing stuff and hoping."

1. Never change behavior and structure in the same commit. Refactoring commits change structure only. Feature commits change behavior only. Mixing them makes rollback impossible and code review meaningless.

2. Never refactor without tests. If tests don't exist, write characterization tests first — tests that capture current behavior, even if that behavior is wrong. Fix the behavior later, separately.

3. One smell at a time, codebase-wide. Fix all any types, then all long functions, then all enums. Don't fix everything in one file — fix one thing across all files. This produces consistent, reviewable diffs.

4. Every step must be independently verifiable. Tests pass after each commit. If a refactoring breaks tests, it's too big — break it into smaller steps.

5. Prefer boring, obvious transformations. Rename a variable. Extract a function. Inline a pointless wrapper. These are safe, reviewable, and reversible. Clever restructuring is risky.

2. Assessment: Read Before You Cut