agentsclimarketplace

Refactor

Skill Brayanhenaor/ai-standards/skills/refactor

Improve the structure of existing code without changing its behavior. Use when asked to refactor, clean up, reduce duplication, or pay down tech debt. Works in small, safe, verifiable steps behind a test safety net — never a big-bang rewrite.From its SKILL.md

Install
npx -y skills add Brayanhenaor/ai-standards --skill 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

  • 1 stars1 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

2.6 KB, as published. Nobody here has run it

Refactor

Refactoring changes structure, not behavior. The code does the same thing afterward — just cleaner. If behavior must change, that's a feature or a fix, not a refactor; say so and treat it as one.

Unlike review (which reports), this skill changes code — so it does so safely.

1. Establish a safety net first

  • Refactoring without tests is just editing and hoping. Before changing behavior-bearing code, make sure there are tests that pin the current behavior.
  • If coverage is missing, write characterization tests first: capture what the code does now (even if imperfect), so any accidental behavior change is caught.
  • Confirm the net is green before touching anything (verify).

2. One transformation at a time

  • Make a single, named refactoring (extract function, rename, introduce parameter object, replace conditional with polymorphism, inline needless indirection…), then re-run the tests.
  • Keep each step small enough that, if a test breaks, the cause is obvious. Commit-sized steps.
  • Never mix refactoring with behavior changes in the same step — they must be distinguishable in the diff and the history.

3. Aim by the hierarchy

  • Target real smells (see clean-code-core/reference/smells.md): duplication of knowledge, long methods, primitive obsession, feature envy, switch-on-type, low cohesion.
  • Move toward clean code and away from over-engineering. Removing a speculative abstraction or a middle-man layer is as valid a refactor as extracting a function. Apply anti-overengineering — but if the abstraction is a seam others depend on, flag it first (see §4) rather than deleting it freely.
  • Stop when the code is clean enough for the change at hand. Don't gold-plate; don't refactor the whole module because you were in there.

4. Respect scope and the project

  • Refactor what the task touches. Flag adjacent debt as [IMPROVEMENT]/[TECHNICAL]; don't silently expand the blast radius.
  • Match the project's existing conventions, not your preferences.
  • Don't break public contracts (APIs, signatures, message schemas) under the banner of "cleanup" without calling it out.

5. Finish verified

End green: tests pass, build clean (verify). State what you changed and confirm behavior is unchanged. Reply in the developer's language; keep code and identifiers in English.

Keep looking

Skills are one crate of 627,801. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.