agentleFS
zekhoizekhoi/claude/.agents/skills/kit-refactoring/SKILL.md

kit-refactoring

Skill0 starsChanged 20 days agoMITView on GitHub

Restructure existing code to improve its design without changing behavior, protected by tests run before and after. Use when the user asks to refactor, clean up, simplify, deduplicate, extract, rename across modules, or reorganize code while keeping it working the same. Do not use for fixing bugs, adding features, or performance work that changes behavior.

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 6 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    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
  1. Distinctive:

    Run the existing tests that cover it and record the result before changing anything.

    line 13
  2. Distinctive:

    If the code has no meaningful tests, add characterization tests that capture current behavior first, including edge cases and current error …

    line 14
  3. Distinctive:

    Follow the project's existing patterns.

    line 20
  4. Distinctive:

    Keep the change focused. Note other improvements you notice instead of making them.

    line 21
  5. Distinctive:

    Run the full relevant test suite, type checks, and linters, and confirm the results match the baseline.

    line 25
  6. Distinctive:

    Use: "Refactor the pricing module to remove the duplicated discount logic." "Split this 600-line file into smaller modules."

    line 30

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Refactoring

A refactoring changes structure, never behavior. If behavior must change, stop and say so; that is a separate change.

1. Pin down current behavior

  • Identify the code in scope and everything that depends on it: callers, exports, public APIs, serialized formats, and configuration.
  • Run the existing tests that cover it and record the result before changing anything.
  • If the code has no meaningful tests, add characterization tests that capture current behavior first, including edge cases and current error behavior, even if that behavior looks wrong. Report anything that looks like a bug instead of fixing it during the refactoring.

2. Refactor in small steps

  • Make one structural change at a time: extract, inline, rename, move, or deduplicate. Run the tests after each meaningful step.
  • Preserve public interfaces unless the user asked to change them. When a rename crosses module boundaries, update every reference; search for dynamic or string-based uses too.
  • Follow the project's existing patterns. Do not introduce new abstractions, frameworks, or dependencies to make the code "cleaner" unless asked.
  • Keep the change focused. Note other improvements you notice instead of making them.

3. Verify and report

  • Run the full relevant test suite, type checks, and linters, and confirm the results match the baseline.
  • Report what was restructured and why it is better, the tests run before and after with their results, any characterization tests added, and suspected bugs left unchanged.

Examples

  • Use: "Refactor the pricing module to remove the duplicated discount logic." "Split this 600-line file into smaller modules."
  • Skip: "Fix the double discount bug." (debugging) "Add coupon support." (feature implementation)

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

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.