$npx -y skills add DevelopersGlobal/ai-agent-skills --skill refactoringSafe, behavior-preserving code transformation backed by tests. Refactor with evidence, not instinct.
| 1 | ## Overview |
| 2 | |
| 3 | Refactoring changes the internal structure of code without changing its external behavior. The keyword is "without" — if behavior changes, it's not refactoring, it's modification. This skill enforces safe refactoring with tests as the safety net. |
| 4 | |
| 5 | ## When to Use |
| 6 | |
| 7 | - When code is hard to understand or extend |
| 8 | - When duplication makes maintenance risky |
| 9 | - Before adding a feature to a messy area of code |
| 10 | - Never: "while also adding feature X" — refactor separately |
| 11 | |
| 12 | ## Process |
| 13 | |
| 14 | ### Step 1: Establish a Safety Net |
| 15 | |
| 16 | 1. Before touching a single line: ensure there are tests covering the code to be refactored. |
| 17 | 2. If tests are missing: add characterization tests first. These capture current behavior, not desired behavior. |
| 18 | 3. Run the tests. They should all pass. This is your baseline. |
| 19 | |
| 20 | **Verify:** Tests pass. They cover the code being refactored. |
| 21 | |
| 22 | ### Step 2: Refactor in Micro-Steps |
| 23 | |
| 24 | 4. Make the smallest meaningful change. |
| 25 | 5. Run tests after EVERY change — not after 10 changes. |
| 26 | 6. If tests break: revert immediately and take a smaller step. |
| 27 | 7. Never batch multiple refactoring changes together. |
| 28 | |
| 29 | **Verify:** Tests pass after every individual change. |
| 30 | |
| 31 | ### Step 3: One Thing at a Time |
| 32 | |
| 33 | 8. Refactoring types cannot be mixed in one step: |
| 34 | - Extract method → separate commit |
| 35 | - Rename → separate commit |
| 36 | - Move → separate commit |
| 37 | 9. "Refactor and also fix this" is not refactoring — it's two PRs. |
| 38 | |
| 39 | **Verify:** This commit does exactly one type of refactoring. |
| 40 | |
| 41 | ### Step 4: Verify No Behavior Change |
| 42 | |
| 43 | 10. Run the full test suite. |
| 44 | 11. If integration/E2E tests exist: run them too. |
| 45 | 12. Compare external API responses before and after (if applicable). |
| 46 | |
| 47 | **Verify:** All tests pass. No observable behavior change. |
| 48 | |
| 49 | ## Common Rationalizations (and Rebuttals) |
| 50 | |
| 51 | | Excuse | Rebuttal | |
| 52 | |--------|----------| |
| 53 | | "I'll add tests after refactoring" | You can't verify a behavior-preserving refactor without tests before the refactor. | |
| 54 | | "This change is obviously safe" | Obvious safety is how production incidents happen. Run the tests. | |
| 55 | | "I'll just do a quick cleanup" | "Quick cleanup" that changes behavior is a bug, not a refactor. | |
| 56 | |
| 57 | ## Verification |
| 58 | |
| 59 | - [ ] Tests existed before any code was changed |
| 60 | - [ ] Tests run after every individual change |
| 61 | - [ ] Only one type of refactoring per commit |
| 62 | - [ ] Full test suite passes at the end |
| 63 | - [ ] No behavior change observable externally |
| 64 | |
| 65 | ## References |
| 66 | |
| 67 | - [test-driven-development skill](../test-driven-development/SKILL.md) |
| 68 | - [simplicity-first skill](../simplicity-first/SKILL.md) |
| 69 | - Martin Fowler, "Refactoring" |