Safe refactor
Behavior-preserving refactoring in small verified steps, with a rollback path at every point.From its SKILL.md
npx -y skills add ayaqen/Agents-Scripts --skill safe-refactorAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
1.8 KB, as published. Nobody here has run it
safe-refactor
Restructure code without changing behavior, in steps small enough that any breakage is instantly attributable.
When to use
- Extracting, renaming, moving, or de-duplicating code.
- Preparing ground for a feature ("make the change easy, then make the easy change").
- NOT for behavior changes — if behavior changes, it's a feature or a fix, and it needs its own commit and tests.
Workflow
- Establish the safety net: run the tests covering the target code and record the result. Coverage thin? Add characterization tests for current behavior before refactoring — they're cheap insurance and a separate commit.
- Plan the end state in one sentence. If you can't, the refactor is too big — split it.
- Move in mechanical steps, each independently green: rename, then move, then reshape — never all at once. Use language tooling (IDE rename, codemods) over hand-editing when available.
- Run the tests after every step. A failure means the last step broke it — revert that step, not the whole effort.
- Commit each coherent step with
refactor(...). Small commits are the rollback path. - Delete the old path. Leaving both "temporarily" creates a fork that drifts; compatibility shims need a named contract (public API, stored data, config), not vague caution.
Pitfalls
- The "while I'm here" trap: folding fixes or features into refactor commits destroys reviewability and bisectability.
- Refactoring against a red baseline — you can no longer tell what you broke.
- Trusting type-checks alone as the safety net; they don't catch behavioral drift in dynamic paths.
- Repo-wide mechanical search-and-replace in one commit; reviewers can't verify it, and one edge case poisons the batch.