refactoring-code-expert
Skill30 starsChanged 4 days agoApache-2.0View on GitHub
Executes structural improvements on existing code to increase maintainability, readability, and extensibility without altering external behavior. Use this skill to address technical debt, fix "Code Smells", apply design patterns, or improve adherence to SOLID principles.
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 4 are distinctive, and 2 are 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.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 27
Verify existing test coverage before editing any code:
- Distinctive: line 31
If tests are absent or inadequate, write minimal "Characterization Tests" to pin down existing behavior before modifying the implementation.
- Very specific: line 43
Run the test suite: python3 ./skills/refactoring-code-expert/scripts/run_tests.py.
- Distinctive: line 44
If green, proceed to the next step.
- Distinctive: line 45
Leave the codebase cleaner than you found it (Boy Scout Rule).
- Very specific: line 60
Claude Code: Run run_tests.py via the bash tool between micro-refactorings to guarantee continuous green state.
≈ “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.
Files
Refactoring Code Expert Skill
Overview
This skill guides safe, disciplined, and incremental structural improvements to existing codebases without modifying external behavior. It acts as a Senior Software Architect and Refactoring Specialist, treating refactoring not as a risky "big-bang rewrite", but as a controlled sequence of micro-transformations protected by a robust automated test safety net.
When to Use
Trigger Scenarios
- Eliminating code smells (God classes, long methods, duplicated logic, high cyclomatic complexity).
- Restructuring messy or legacy code to adhere to SOLID, DRY, and KISS principles.
- Decoupling tightly coupled components using Dependency Inversion or Ports & Adapters.
- Preparing a module for new features by first making the change easy (pre-factoring).
When NOT to Use
- Adding new functional capabilities or modifying contracts: Route to
code-implementerortest-driven-development. - Pure smell diagnosis without altering code: Route to
code-smells-expert. - Database schema modifications: Route to
database-migration-expert. - Authoring new architectural specifications: Route to
senior-architect-engineering.
Process
Phase 1: Test Safety Net & Characterization
- The Golden Rule: Refactoring changes internal structure, NEVER external behavior. If observable behavior changes, the refactoring is broken.
- Verify existing test coverage before editing any code:
python3 ./skills/refactoring-code-expert/scripts/run_tests.py - If tests are absent or inadequate, write minimal "Characterization Tests" to pin down existing behavior before modifying the implementation.
Phase 2: Micro-Refactoring Sequence Plan
Formulate a sequence of atomic, low-risk micro-refactorings:
- Extract Method / Function: Isolate cohesive blocks of logic into well-named functions.
- Introduce Parameter Object: Group related parameters into a dataclass or value object.
- Replace Conditional with Polymorphism: Replace complex
if/elseorswitchtrees with strategy classes. - Rename Symbol: Replace cryptic names with self-documenting domain identifiers.
Phase 3: Incremental Execution Loop
Execute the changes one step at a time:
- Apply a single micro-refactoring.
- Run the test suite:
python3 ./skills/refactoring-code-expert/scripts/run_tests.py. - If green, proceed to the next step. If red, undo immediately and diagnose before proceeding.
- Leave the codebase cleaner than you found it (Boy Scout Rule).
Usage
Commands & Automation Scripts
# Detect and execute test suite before and after refactorings
python3 ./skills/refactoring-code-expert/scripts/run_tests.pyExample Prompts
- "Refactor this 250-line order processing function to extract validation and payment logic, keeping all tests passing."
- "Refactor this legacy user manager class to decouple it from direct database queries via repository interfaces."
- "Apply the strategy pattern to clean up this large nested switch statement in our shipping rate calculator."
Host Execution Instructions
- Claude Code: Run
run_tests.pyvia the bash tool between micro-refactorings to guarantee continuous green state. - Antigravity: Apply changes incrementally, verifying test suite execution at each step before completing the turn.
Red Flags
- Changing external API behavior or function return signatures while claiming to refactor.
- Refactoring without a green, passing test suite.
- Attempting a large-scale rewrite all at once rather than baby steps.
- Introducing complex design patterns where a simple function extraction would suffice.
- Commenting out tests or assertions to make a refactored module pass.
Verification
- 100% of unit and integration tests pass before starting and after completion.
- Automated test runner exits cleanly with zero failures:
python3 ./skills/refactoring-code-expert/scripts/run_tests.py - Public interfaces, schemas, and observable behaviors remain strictly identical.
- Target code smells and cyclomatic complexity are demonstrably reduced.
References
For detailed catalogs of code transformations and step-by-step mechanics:
- Refactoring Techniques Reference
In this repository40 other files it gives its agents.
- AGENTS.mdAGENTS.md
- adversarial-challengerSkill
- agent-metricsSkill
- bigquery-query-optimizationSkill
- blackbox-testerSkill
- build-and-ci-gatesSkill
- cdc-scd-patternsSkill
- code-criticSkill
- code-implementerSkill
- code-smells-expertSkill
- commit-expertSkill
- compliance-verifierSkill
- context-captureSkill
- context-restoreSkill
- database-migration-expertSkill
- design-spec-expertSkill
- documentation-expertSkill
- flutter-architecture-decisionsSkill
- flutter-performance-profilingSkill
- flutter-release-engineeringSkill
- flutter-review-checklistSkill
- flutter-senior-orchestrationSkill
- flutter-test-strategySkill
- flutter-upgrade-migrationSkill
- gcp-data-engineeringSkill
- guidelines-karpathySkill
- loop-engineeringSkill
- performance-scalabilitySkill
- product-analystSkill
- pull-request-expertSkill
- python-expertSkill
- qa-testerSkill
- repo-researchSkill
- security-auditSkill
- senior-architect-engineeringSkill
- senior-dev-orchestratorSkill
- sql-query-optimizationSkill
- test-driven-developmentSkill
- testing-expertSkill
- ui-ux-designerSkill
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.

