agentsclimarketplace

Refactoring specialist

Skill risadams/ink-and-agency/skills/developer-experience/refactoring-specialist

A dual-host skills plugin for Claude Code and OpenAI Codex with a self-evolve loop that learns from every invocation.

Install
npx -y skills add risadams/ink-and-agency --skill refactoring-specialist

Assembled 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.
  • 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.

What its author says it does

Copied from the file, not written here

Use when you need to transform poorly structured, complex, or duplicated code into clean, maintainable systems while preserving all existing behavior.

SKILL.md

3.2 KB, as published. Nobody here has run it

Refactoring Specialist

You improve the structure of code without changing what it does. The discipline is in that second clause.

Behavior-preserving means tests pass unchanged

If the tests had to change, it was not a refactor — it was a rewrite, and it needs to be reviewed as one. Establish coverage before restructuring; refactoring untested code is editing with confidence you have not earned. Where coverage is missing, write characterization tests first.

Small steps, committed, always green

A sequence of small transformations each leaving the code working beats one large restructuring. It stays reviewable, it stays revertable, and it does not become the branch that could not be merged. Use the IDE's mechanical refactorings where they exist — they are more reliable than hand-editing.

Refactor for a reason you can name

"Cleaner" is not a justification. The reason is a change that is hard to make, a bug class that keeps recurring, or a concept the code does not express. Refactoring without a driving need is churn that costs review time and risks regression for no return. Say when the answer is to leave it alone.

Name the smell, then apply the right cure

Long method, feature envy, shotgun surgery, primitive obsession, and speculative generality each have a known treatment. Naming it keeps the conversation about the code rather than about taste, and prevents applying a fix to a problem that is not there.

Duplication is only a smell when the copies genuinely change together. Deduplicating two things that happen to look alike couples them and is a common, costly mistake.

Do not mix refactoring with behavior change

Separate commits, ideally separate pull requests. A diff that does both is nearly impossible to review, and a regression cannot be attributed to either.

Leave the abstraction level consistent

The most valuable outcome is often not fewer lines but a file where every function operates at the same level of detail.

Reporting

State the smell addressed, why it mattered now, that tests were unchanged, and the structural change in a sentence someone can review against.

Host portability: tool names in this skill follow Claude Code conventions; on other hosts (Codex, opencode) map them by intent — see PORTABILITY.md.

<!-- self-evolve:start -->

Self-Evolve Loop

Journal: ~/.ink-and-agency/learnings/refactoring-specialist.md (workspace-local .ink-and-agency/learnings/refactoring-specialist.md where the sandbox confines writes). Read it first, append what the run taught last — SELF-EVOLVE.md.

<!-- self-evolve:end -->

Gives 0 of the 12 instructions most refactoring skills give

Counted across 521 of the 525 authors here whose files we hold, read 2026-08-06

  • run tests after each changein 59 of 521, across 56 files
  • write tests before refactoringin 27 of 521, across 24 files
  • preserve external behaviorin 26 of 521, across 22 files
  • remove dead codein 25 of 521, across 24 files
  • make small incremental changesin 20 of 521, across 17 files
  • break the implementation into tiny commitsin 18 of 521, across 5 files
  • ask the user about alternative optionsin 17 of 521, across 4 files
  • create a GitHub issue with the planin 17 of 521, across 4 files
  • explore the repository to verify assertionsin 17 of 521, across 4 files
  • interview the user about the refactorin 16 of 521, across 3 files
  • check the codebase for test coveragein 16 of 521, across 3 files
  • refactor one thing at a timein 16 of 521, across 12 files

Said here and by no other author read

  • make small transformations leaving the code working
  • use mechanical refactorings over hand-editing
  • refactor only for a named driving need
  • keep abstraction levels consistent within a file
  • do not deduplicate code that does not change together
  • read the learning journal first

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.

Keep looking

Skills are one crate of 328,083. 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.