19 lines
1.1 KiB
Markdown
19 lines
1.1 KiB
Markdown
---
|
|
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.
|