How do I install the Refactoring skill?

Run npx skillmds@latest add developersglobal/refactoring in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Refactoring safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Refactoring?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Refactoring free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Refactoring?

DevelopersGlobal (@developersglobal) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Refactoring by developersglobal — Agent Skill

Name: Refactoring
Rating: 4.2 (5 reviews)
Author: DevelopersGlobal

File contents

Overview

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.

When to Use

When code is hard to understand or extend
When duplication makes maintenance risky
Before adding a feature to a messy area of code
Never: "while also adding feature X" — refactor separately

Process

Step 1: Establish a Safety Net

Before touching a single line: ensure there are tests covering the code to be refactored.
If tests are missing: add characterization tests first. These capture current behavior, not desired behavior.
Run the tests. They should all pass. This is your baseline.

Verify: Tests pass. They cover the code being refactored.

Step 2: Refactor in Micro-Steps

Make the smallest meaningful change.
Run tests after EVERY change — not after 10 changes.
If tests break: revert immediately and take a smaller step.
Never batch multiple refactoring changes together.

Verify: Tests pass after every individual change.

Step 3: One Thing at a Time

Refactoring types cannot be mixed in one step:
- Extract method → separate commit
- Rename → separate commit
- Move → separate commit
"Refactor and also fix this" is not refactoring — it's two PRs.

Verify: This commit does exactly one type of refactoring.

Step 4: Verify No Behavior Change

Run the full test suite.
If integration/E2E tests exist: run them too.
Compare external API responses before and after (if applicable).

Verify: All tests pass. No observable behavior change.

Common Rationalizations (and Rebuttals)

Excuse	Rebuttal
"I'll add tests after refactoring"	You can't verify a behavior-preserving refactor without tests before the refactor.
"This change is obviously safe"	Obvious safety is how production incidents happen. Run the tests.
"I'll just do a quick cleanup"	"Quick cleanup" that changes behavior is a bug, not a refactor.

Verification

Tests existed before any code was changed
Tests run after every individual change
Only one type of refactoring per commit
Full test suite passes at the end
No behavior change observable externally

References

---name: refactoringdescription: Safe, behavior-preserving code transformation backed by tests. Refactor with evidence, not instinct.--- ## Overview 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. ## When to Use - When code is hard to understand or extend - When duplication makes maintenance risky - Before adding a feature to a messy area of code - Never: "while also adding feature X" — refactor separately ## Process ### Step 1: Establish a Safety Net 1. Before touching a single line: ensure there are tests covering the code to be refactored. 2. If tests are missing: add characterization tests first. These capture current behavior, not desired behavior. 3. Run the tests. They should all pass. This is your baseline. **Verify:** Tests pass. They cover the code being refactored. ### Step 2: Refactor in Micro-Steps 4. Make the smallest meaningful change. 5. Run tests after EVERY change — not after 10 changes. 6. If tests break: revert immediately and take a smaller step. 7. Never batch multiple refactoring changes together. **Verify:** Tests pass after every individual change. ### Step 3: One Thing at a Time 8. Refactoring types cannot be mixed in one step: - Extract method → separate commit - Rename → separate commit - Move → separate commit 9. "Refactor and also fix this" is not refactoring — it's two PRs. **Verify:** This commit does exactly one type of refactoring. ### Step 4: Verify No Behavior Change 10. Run the full test suite. 11. If integration/E2E tests exist: run them too. 12. Compare external API responses before and after (if applicable). **Verify:** All tests pass. No observable behavior change. ## Common Rationalizations (and Rebuttals) | Excuse | Rebuttal | |--------|----------| | "I'll add tests after refactoring" | You can't verify a behavior-preserving refactor without tests before the refactor. | | "This change is obviously safe" | Obvious safety is how production incidents happen. Run the tests. | | "I'll just do a quick cleanup" | "Quick cleanup" that changes behavior is a bug, not a refactor. | ## Verification - [ ] Tests existed before any code was changed - [ ] Tests run after every individual change - [ ] Only one type of refactoring per commit - [ ] Full test suite passes at the end - [ ] No behavior change observable externally ## References - [test-driven-development skill](../test-driven-development/SKILL.md) - [simplicity-first skill](../simplicity-first/SKILL.md) - Martin Fowler, "Refactoring"

Frequently asked questions

Refactoring