safe-refactoring
Skill17 starsChanged 58 days agoMITView on GitHub
Refactor code safely through behavior preservation, protective tests, incremental change sequencing, and risk-aware migration planning.
3 other projects use a version of this.
Adopted by
Most recently taken up by
- yuchi-chang/no-capetheir own version, first seen Oct 8, 2026
- varunk130/ai-workflow-playbookstheir own version, first seen May 22, 2026
- codecharmhq/claude-code-skillstheir own version, first seen May 17, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 3
- varunk130/ai-workflow-playbooks★ 2same name
- yuchi-chang/no-cape★ 2same name
- codecharmhq/claude-code-skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository22 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- adr-challengerSkill
- api-designSkill
- architecture-decisionsSkill
- async-systemsSkill
- code-reviewSkill
- database-engineeringSkill
- dora-metricsSkill
- engineering-economicsSkill
- incident-responseSkill
- nestjs-architecture-guardianSkill
- node-runtime-reliabilitySkill
- observabilitySkill
- performance-analysisSkill
- prd-reviewSkill
- production-readinessSkill
- release-planningSkill
- repo-onboardingSkill
- security-reviewSkill
- systematic-debuggingSkill
- test-strategySkill
The file
We split this skill into the rules it gives an agent
1 rule. 0 are common, 1 is distinctive, and 0 are very specific to this project.
0
Common
Most of the 3 edited versions we read keep these.
1
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 19
Hands off to: test-strategy (protective tests), code-review (review the refactor), release-commander (if affects production behavior).
“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Mission
Improve code structure without silently changing system behavior or increasing delivery risk.
When to use
- Cleaning up legacy code.
- Extracting modules or services.
- Reducing coupling.
- Introducing clearer abstractions.
- Reorganizing domain boundaries.
Handoff
- Receives from: code-review (identified tech debt) or backend-platform-engineer (planned improvement).
- Hands off to: test-strategy (protective tests), code-review (review the refactor), release-commander (if affects production behavior).
The safe refactoring method
1. CHARACTERIZE → Write tests that capture current behavior (before changing anything)
2. IDENTIFY → What exactly needs to change? What must stay the same?
3. PLAN → Break the refactor into small, independently-mergeable steps
4. EXECUTE → One step at a time. Each step: green tests → change → green tests
5. VALIDATE → Run full test suite. Check no behavioral regression.
6. DEPLOY → Ship incrementally. Monitor for unexpected changes.Refactor vs rewrite decision
| Choose refactor when | Choose rewrite when |
| Core behavior is correct, structure is bad | Core behavior is wrong |
| Tests exist or can be written | System is so tangled tests can't be written |
| Team needs to maintain it during refactor | Clean break is possible (new service, new module) |
| Incremental delivery is possible | All-or-nothing is the only realistic path |
Default to refactor. Rewrites are almost always more expensive than estimated.
Common refactoring pitfalls
- Changing behavior accidentally while restructuring.
- Removing "unused" code that's actually called via reflection or config.
- Breaking error semantics (different exception types, different HTTP codes).
- Changing timing that affects distributed flows.
- Losing observability (spans, metrics, log lines removed).
Red flags — stop and reassess if
- You can't write a characterization test for the current behavior.
- The refactor touches more than 3 modules simultaneously.
- The refactor requires coordinated changes across services.
- There's no way to deploy the refactor incrementally.
- You find yourself saying "while we're at it, let's also..."
Output format
- Current problems (what's wrong with the current structure)
- Preserved behavior (what must not change)
- Refactor strategy (numbered steps, each independently mergeable)
- Protective tests (what to write before starting)
- Risk assessment (what could go wrong, how to detect it)
- Migration plan (if contracts or APIs change)
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.