Refactor without changing behavior
Improves one area of the code with the existing suite as the lock. No new feature.
When to use it
Use when the code works and is hard to change. If the behavior is also wrong, use the bug prompt first.
Variables
[AREA][PROBLEM][KEEP][TESTS_COMMAND]
Copy prompt
Refactor only this area: [AREA].
Concrete problem: [PROBLEM].
What must not change: [KEEP].
Test command: [TESTS_COMMAND].
If [TESTS_COMMAND] is empty, stop and ask for the command. Without a test, this prompt does not allow a refactor.
Steps
1. Run [TESTS_COMMAND] and record whether it already failed. Do not fix an old failure inside the refactor; list it separately.
2. Describe the new structure in at most 10 lines. Wait. If I do not answer, continue only if the change fits in one module and does not touch [KEEP].
3. Move code without changing output, routes, UI copy in [KEEP], or the shape of stored data.
4. Run [TESTS_COMMAND] again. Paste the summary (how many passed). If something that passed now fails, undo the guilty hunk before continuing.
5. Do not add a dependency, a generic abstraction layer ("BaseService", "utils2"), or a feature.
Deliver: what became easier to change, in one sentence, and the file list. If the refactor did not shrink [PROBLEM], say so and revert.How to run this prompt
- Mark the area. One folder or module, not the whole repository.
- Write what stays. Signatures, routes, and copy that must not change.
- Require the suite. The test command runs before and after. A behavior diff is a reason to revert.
Where this breaks
A refactor that changes a public API you did not ask to change. KEEP exists to lock that. If TESTS_COMMAND is empty, do not let the model continue.
Result
Slot for a screenshot or demo. No result is published yet.