incomplete-refactor
Skill1 starsChanged 5 days agoMITView on GitHub
Detect an incomplete refactor — old names still referenced, removed files still present, stale tests still calling the old API — before calling the refactor done. Use after every rename, move, or API migration, and in CI on refactor branches. A green test suite does not prove a refactor is complete. Only invoke via the orcinus router.
In this repository35 other files it gives its agents.
- accessibilitySkill
- api-and-interface-designSkill
- architectureSkill
- ask-questions-if-underspecifiedSkill
- breaking-changeSkill
- buildSkill
- codebase-knowledge-builderSkill
- database-designerSkill
- diagnosing-bugsSkill
- finalizeSkill
- frontend-architectureSkill
- frontend-data-contractsSkill
- frontend-optimistic-mutationsSkill
- handoffSkill
- i18nSkill
- idea-calibrateSkill
- idea-captureSkill
- independent-reviewSkill
- issue-triageSkill
- mcp-builderSkill
- monitoring-observabilitySkill
- monitoringSkill
- mutation-testing-pythonSkill
- mutation-testingSkill
- orcinusSkill
- orcinus-verifySkill
- performance-optimizationSkill
- refactorSkill
- registry-publishSkill
- scaffoldSkill
- security-reviewSkill
- skill-creatorSkill
- visual-regressionSkill
- wazaSkill
- webapp-testingSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 4 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 16
Run the checker before calling the refactor done.
- Distinctive: line 18
Every allowlist entry must be justified in the report.
- Distinctive: line 19
Never delete the checker's output.
- Distinctive: line 25
Write down, before touching code:
- Very specific: line 33
Do the refactor (rename, move, migrate) one slice at a time, following build.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 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.
Files
INCOMPLETE-REFACTOR — is the old thing really gone?
A refactor is done only when the old thing is gone everywhere: code, tests, docs, config. A green suite does not prove that. The compiler does not read docs, dead code compiles, and a test that still calls the old name is a test the refactor never reached. This skill checks the refactor's own definition of done, with a script, not by eye.
Rules
- Define the scope before refactoring: the old identifiers, the paths that must disappear, and the new names. A refactor without a written scope cannot be checked.
- Run the checker before calling the refactor done. A leftover is a finding, not a note.
- The checker supplements the four commands (build, lint, typecheck, test); it does not replace them. Both must be green.
- Every allowlist entry must be justified in the report. An allowlist that hides a leftover is a lie.
- Never delete the checker's output. It is the evidence the refactor finished.
Steps, in order
1. Scope
Write down, before touching code:
- Old identifiers: every function, type, variable, and file name that must disappear (for example
budgetWarning). - Removed paths: every file or directory that must no longer exist (for example
src/budget-old.ts). - Allowlist: the files allowed to mention an old name on purpose — a CHANGELOG entry, a migration guide. Each entry needs a reason.
2. Refactor
Do the refactor (rename, move, migrate) one slice at a time, following build.
3. Run the checker
python3 skills/incomplete-refactor/scripts/check_refactor.py \
--root . \
--old budgetWarning \
--removed src/budget-old.ts \
--allow CHANGELOG.mdIt exits 0 when clean and 1 when it finds a leftover — or when the scan was incomplete (a file it could not read, a root that does not exist, an empty --old list, a symlink pointing outside the root). It scans the files git knows about (tracked plus untracked, respecting .gitignore); when the root is not a git repository it walks the tree and skips generated directories and lockfiles (overridable with --skip-dirs / --skip-files). The allowlist matches a relative path only, never a bare basename (--allow ./CHANGELOG.md works). A symlink whose target stays inside the root is read; one pointing outside it is not read. It reports:
- Old identifier still referenced, with file and line — including in tests (a stale test) and in docs and comments (a forgotten mention). Identifiers that start with
$are matched as whole identifiers. - Removed path still present.
- TODO or FIXME comments that name the old identifier — a migration the refactor left half-done.
- How many files were checked, skipped (generated dirs/lockfiles), skipped (non-UTF-8), binary, unreadable, and skipped (symlink outside the scan root). A clean result covers only the files scanned — generated dirs, lockfiles and outside symlinks are not scanned, and the summary says how many. A scan that did not cover everything is INCOMPLETE, never clean.
4. Run the four commands
Build, lint, typecheck, test. A leftover the compiler catches is still a leftover; a leftover the compiler does not catch is the reason this skill exists.
5. Verdict
- PASS: the checker is clean and the four commands are green. The refactor is done.
- FAIL: any leftover, or any red command. Fix the leftover — do not add it to the allowlist to make the report green.
Report
Return the report in this form:
- Scope: old identifiers, removed paths, allowlist with a reason per entry.
- The exact checker command and its exit code.
- Each leftover, with file, line, and kind (old name / removed path / stale test).
- The four commands and their results.
- Verdict: PASS or FAIL, and what remains.
Scope
Textual leftovers only. The checker finds names and paths; it does not find semantic incompleteness — duplicated logic under a different name, or a call site that was deleted instead of migrated. Those are caught by tests, coverage, and review, not by this checker. A bare "TODO: migrate" that never names the old thing is a human-review item, not a checker item.
Sources
Written from scratch for ORCINUS. No ready skill was found for this in the 0–100 research: generic refactoring skills (for example code-refactoring-skill, MIT) teach how to refactor, none check that a refactor actually finished. The checker script is original code, shipped under this repo's MIT licence.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
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.

