refactor

name	refactor
description	Safe, systematic refactoring workflow — same behavior, better structure

Execute a safe, systematic refactoring workflow on the target scope.

Task: the task/scope the user described when invoking this skill (if none given, ask or infer from context)

Phase 1: Analysis

Do the analysis yourself:

• Code smells (see ~/.codex/skills/code-smells): long functions, deep nesting, duplication, large classes, long parameter lists, feature envy, primitive obsession, dead code.
• Dependencies & coupling: map module dependency direction, identify tight coupling and leaf vs core modules. Synthesize into a unified findings list.

Phase 2: Refactoring Plan

Present findings with severity ratings. Create a safe refactoring order based on:

1. Dependency direction (leaf modules first, core last)
2. Test coverage (well-tested first; untested code needs characterization tests first)
3. Risk level (pure functions → utilities → business logic → public API)

Each step specifies: target file(s), smell addressed, refactoring pattern (Extract Method, Move Function, Replace Conditional with Polymorphism, etc.), and that behavior MUST remain identical.

Wait for user approval before proceeding.

Phase 3: Test Baseline

1. Run the full test suite → record baseline pass count.
2. If no tests exist for target code, write characterization tests first.
3. Store baseline: build PASS | lint PASS | test X/Y PASS.

Phase 4: Execution

For each approved step:

1. Apply ONE refactoring pattern at a time.
2. Run build + lint + test immediately after.
3. Tests fail → revert that step and report. Never fix forward.
4. Tests pass → commit atomically (refactor(scope): pattern applied) → next step. Execute sequentially in leaf → root order (dependent modules strictly sequential).

Phase 5: Verification

Run full build + lint + full test suite. Compare test count: baseline vs current (must be equal or greater). Distinguish failure cause:

• Breakage caused by a refactoring step (green before, now fails) → revert that step immediately.
• Pre-existing failures or environment/build issues unrelated to the refactor → fix separately (root-cause, minimal diffs), don't revert refactoring.

Phase 6: Review

Review the refactoring yourself: verify (1) no behavior changes, (2) improved structure, (3) no regressions.

Phase 7: Report

## Refactoring Report
### Before → After
| Metric | Before | After |
| Files changed / Lines removed / Lines added / Avg function length / Max nesting / Test count |
### Applied Refactorings
| # | Pattern | Target | Result |
### Smells Resolved
- [x] ...
### Remaining (deferred)
- [ ] ... — reason
### Verification
Build: PASS | Lint: PASS | Tests: X/Y PASS

Rules

• NEVER change behavior. Refactoring = same behavior, better structure.
• ONE pattern per commit — easy to revert.
• TEST FIRST. No refactoring without a green baseline.
• If a step breaks a previously-green test, revert that step immediately — don't fix forward.
• Don't refactor code you don't understand. Read it first.
• Preserve public API unless the user explicitly approves breaking changes.