Refactor module

Skill tmj-90/gaffer/runner/skills/refactor-module

Self-hosted AI coding factory — sandboxed agents deliver tickets to merged code, gated by a human in a dashboard. Local-first, cost-transparent, human-in-the-loop.

Install

npx -y skills add tmj-90/gaffer --skill refactor-module

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

0 stars0 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 a ticket asks to restructure code without changing what it does — extract a function, split a file, rename for clarity, reduce duplication — with behaviour preserved. Invoke for "refactor X", "clean up the Y module", or "extract Z" where no behaviour change is intended.

SKILL.md

2.0 KB, as published. Nobody here has run it

Refactor a module

A refactor changes structure, not behaviour. The contract: tests are green before you start and green after, with no scope creep into new features or fixes.

Steps

Establish the safety net. Run the suite first (run-tests) and confirm it's green. If the module under refactor is thinly tested, add characterization tests (the add-unit-test skill) that pin the current behaviour before you touch anything.
Read the lore. Call search_lore (Memory MCP) for the repo's module boundaries, layering, and naming conventions so the new structure fits the codebase.
Refactor in small, behaviour-preserving steps — extract, rename, move, dedupe — re-running tests after each step. Keep the public interface stable unless the ticket explicitly allows changing it; update call sites if you do.
Change no behaviour. No new features, no bug fixes, no dependency changes riding along. If you spot a real bug, note it for a separate ticket — don't fix it here.
Confirm green after. Run the full suite and lint (run-tests, run-lint) and confirm identical behaviour and no new failures.
Evidence: before/after passing summaries (proving behaviour preserved) and a diff_summary. Then use the record-evidence skill and submit for review.

Rules

Behaviour-preserving only: tests green before and after, same outcomes.
No scope creep — no features, fixes, or dependency bumps in a refactor ticket.
Keep the public interface stable unless the AC says otherwise.
If you uncover a bug, log it separately; don't fix it inside the refactor.
Run on a branch (the create-branch skill), never a protected branch.

Gives 1 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 changehere, and in 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

search existing module lore and conventions
change no behaviour
record before and after passing summaries
record a diff summary
submit for review

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