Safe refactoring
no-cape keeps the knowledge and drops the cape.
npx -y skills add yuchi-chang/no-cape --skill safe-refactoringAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 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.
What its author says it does
Copied from the file, not written here
Use when restructuring, renaming, moving, or extracting code that already works — before making the first edit
SKILL.md
1.7 KB, as published. Nobody here has run it
Safe Refactoring
A refactor changes structure, never behavior. The moment behavior changes, it's not a refactor — split it out.
Rules
- Never mix restructure and behavior change. Behavior-preserving moves in one commit; behavior changes in another. A reviewer must be able to skim the refactor commit and trust it's mechanical.
- Green before, green between, green after. Run tests before starting (know the baseline), after each mechanical step, and at the end. If tests were already red, stop and report — new breakage and old breakage become indistinguishable.
- Find every reference before renaming or removing. Grep beyond what the compiler sees: string references, reflection, config files, serialized field names, SQL, API routes, environment variables, docs. The compiler only checks the typed half.
- Public surface needs a transition. Anything external callers depend on (API endpoint, exported function, published schema) gets a deprecation period or an adapter, not an in-place break.
- Small steps that each leave the build working. If you must hold five files in your head to know it still compiles, the step is too big.
Stop rules
- A "rename" starts requiring logic edits → behavior is changing; stop and separate the two.
- Tests fail mid-refactor in a way you didn't predict → you misunderstood a dependency; investigate before continuing, don't patch around it.
Smell test
Could someone review the diff and verify it's behavior-preserving without running it? If not, the steps are too large or the concerns are mixed.