Test preserving refactor

Skill yeaight7/agent-powerups/skills/test-preserving-refactor

Curated power-ups for coding agents: skills, slash commands, MCP configs, hooks, AGENTS.md templates, and workflows for serious software engineering. Claude Code, Codex, Antigravity CLI, Cursor and more

Install

npx -y skills add yeaight7/agent-powerups --skill test-preserving-refactor

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

6 stars6 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.

What its author says it does

Copied from the file, not written here

Use when code needs restructuring and observable behavior must stay unchanged, with existing tests kept green at every step.

SKILL.md

2.5 KB, as published. Nobody here has run it

Purpose

Refactoring is only safe if it is backed by tests. Work in a strict loop — green baseline, one structural change, immediate re-run, revert on red — so you are never trapped in an uncompilable state.

When to Use

Code needs restructuring (extract/inline/move) without behavior change
A previous refactor spiraled into a broken, hard-to-recover state
Tests covering the target area exist or can be run

Inputs

The target area and the command that runs just its tests

Workflow

Run tests first. Before touching any code, run the tests covering the target area. They MUST be green. If they are red, stop and fix the tests (or the code) first:
```
npx jest path/to/target           # or: pytest tests/test_target.py -q
```
Small steps. Make one structural change at a time (e.g., extract a method).

Run tests immediately after the single structural change. The per-change loop:

# repeat per structural change: edit -> test -> commit (green) | revert (red)
npx jest path/to/target && git commit -am "refactor: extract X" || git checkout -- .

Revert on red. If the tests fail, you made a mistake. Revert the change (git checkout -- . or git restore .) and try a different approach. Do not attempt to "fix" the refactor while tests are failing.
Commit on green. Once the small change is green, consider it a safe checkpoint.

This strict loop prevents you from getting trapped in an uncompilable state.

Output

A chain of small, individually green commits
The final test run output proving unchanged behavior

Verification

Baseline test run was green before the first edit
Exactly one structural change per test cycle
Every red result handled by revert, not forward-fixing
Each green step committed as a checkpoint
No test was modified to make the refactor pass

Failure Modes

Refactoring on red — starting from failing tests means you cannot tell what you broke.
Step batching — three changes per test run; when it fails, you don't know which one did it.
Forward-fixing a broken refactor — "fixing" while red digs the hole deeper; revert is cheaper.
Bending the tests — editing assertions to match new behavior is a behavior change, not a refactor.