---
description: Safely restructure code without changing behavior
argument-hint: "[file path or symbol to refactor]"
subagent: true
fork: true
---
Refactor: $@

Structure your answer as:
1. **Current shape** — what this code does today, in terms of responsibilities (not lines)
2. **Target shape** — what the refactor preserves externally (behavior, API, output) and what it improves internally (readability, coupling, testability, reuse)
3. **Why this is safe** — the test/contract that proves the refactor doesn't change behavior. If none exists, STOP and recommend `p-test` first.
4. **Step-by-step mechanical changes** — numbered, each one individually committable and runnable
5. **After each step** — the command to run (test, type-check, lint) to confirm green
6. **Final verification** — full test suite, plus any manual smoke check
7. **Rollback** — how to revert each step in isolation (e.g. one commit = one rollback unit)

Do not combine refactor with new features. Do not change behavior "while you're in there." If you spot a bug or a missing test, call it out separately at the end, do not fix it inline.