🎯

refactoring-surgeon

🎯Skill

from erichowens/some_claude_skills

VibeIndex|
What it does

refactoring-surgeon skill from erichowens/some_claude_skills

πŸ“¦

Part of

erichowens/some_claude_skills(148 items)

refactoring-surgeon

Installation

Add MarketplaceAdd marketplace to Claude Code
/plugin marketplace add erichowens/some_claude_skills
Install PluginInstall plugin from marketplace
/plugin install adhd-design-expert@some-claude-skills
Install PluginInstall plugin from marketplace
/plugin install some-claude-skills@some-claude-skills
git cloneClone repository
git clone https://github.com/erichowens/some_claude_skills.git
Claude Desktop ConfigurationAdd this to your claude_desktop_config.json
{ "mcpServers": { "prompt-learning": { "command": "npx", "args...
πŸ“– Extracted from docs: erichowens/some_claude_skills
16Installs
21
-
Last UpdatedJan 23, 2026

Skill Details

SKILL.md

"Expert code refactoring specialist for improving code quality without changing behavior. Activate on: refactor, code smell, technical debt, legacy code, cleanup, simplify, extract method, extract class, DRY, SOLID principles. NOT for: new feature development (use feature skills), bug fixing (use debugging skills), performance optimization (use performance skills)."

Overview

# Refactoring Surgeon

Expert code refactoring specialist focused on improving code quality without changing behavior.

Quick Start

  1. Ensure tests exist - Never refactor without a safety net
  2. Identify the smell - Name the specific code smell you're addressing
  3. Make small changes - One refactoring at a time, commit frequently
  4. Run tests after each change - Behavior must remain identical
  5. Don't add features - Refactoring β‰  enhancement
  6. Document significant changes - Explain the "why" for future maintainers

Core Capabilities

| Category | Techniques |

|----------|------------|

| Extraction | Extract Method, Extract Class, Extract Interface |

| Movement | Move Method, Move Field, Inline Method |

| Simplification | Replace Conditional with Polymorphism, Decompose Conditional |

| Organization | Introduce Parameter Object, Replace Magic Numbers |

| Legacy Migration | Strangler Fig, Branch by Abstraction, Parallel Change |

Code Smells Reference

Bloaters

```

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”

β”‚ Long Method β”‚ β”‚ Large Class β”‚ β”‚ Long Parameter β”‚

β”‚ > 20 lines? β”‚ β”‚ > 200 lines? β”‚ β”‚ List β”‚

β”‚ β†’ Extract Method β”‚ β”‚ β†’ Extract Class β”‚ β”‚ β†’ Parameter Object β”‚

β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

```

OO Abusers

```

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”

β”‚ Switch Statements β”‚ β”‚ Refused Bequest β”‚ β”‚ Parallel β”‚

β”‚ Type-checking? β”‚ β”‚ Unused inheritance?β”‚ β”‚ Hierarchies β”‚

β”‚ β†’ Polymorphism β”‚ β”‚ β†’ Delegation β”‚ β”‚ β†’ Move Method β”‚

β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

```

Change Preventers

```

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”

β”‚ Divergent Change β”‚ β”‚ Shotgun Surgery β”‚

β”‚ One class, many β”‚ β”‚ One change, many β”‚

β”‚ reasons to change? β”‚ β”‚ classes affected? β”‚

β”‚ β†’ Extract Class β”‚ β”‚ β†’ Move/Inline β”‚

β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

```

Reference Examples

Complete refactoring examples in ./references/:

| File | Pattern | Use Case |

|------|---------|----------|

| extract-method.ts | Extract Method | Long methods β†’ focused functions |

| replace-conditional-polymorphism.ts | Replace Conditional | switch/if β†’ polymorphic classes |

| introduce-parameter-object.ts | Parameter Object | Long params β†’ structured objects |

| strangler-fig-pattern.ts | Strangler Fig | Legacy code β†’ gradual migration |

Anti-Patterns (10 Critical Mistakes)

1. Big Bang Refactoring

Symptom: Rewriting entire modules in one massive change

Fix: Strangler fig pattern, small incremental changes with tests

2. Refactoring Without Tests

Symptom: Changing structure without test coverage

Fix: Write characterization tests first, add coverage for affected areas

3. Premature Abstraction

Symptom: Creating generic frameworks "for future flexibility"

Fix: Wait for three concrete examples before abstracting (Rule of Three)

4. Renaming Without IDE Support

Symptom: Find-and-replace that misses occurrences

Fix: Use IDE refactoring tools, search for usages first

5. Mixing Refactoring and Features

Symptom: Adding new functionality while restructuring

Fix: Separate commits - refactor first, then add features

6. Ignoring Code Reviews

Symptom: Large refactoring PRs that are hard to review

Fix: Small, focused PRs with clear commit messages

7. Over-Abstracting

Symptom: Three layers of abstraction for a simple operation

Fix: YAGNI - start concrete, abstract when patterns emerge

8. Incomplete Refactoring

Symptom: Starting Extract Method but leaving partial duplication

Fix: Complete the refactoring or revert - no half-measures

9. Refactoring Production During Incidents

Symptom: "I'll just clean this up while I'm here..."

Fix: Never refactor during incidents - fix the bug, create a ticket

10. Not Measuring Improvement

Symptom: Refactoring without knowing if it helped

Fix: Track metrics: complexity, test coverage, build time

Safety Checklist

Before Refactoring:

  • [ ] Code compiles/runs successfully
  • [ ] All tests pass
  • [ ] Test coverage is adequate for area being refactored
  • [ ] Commit current state (can rollback)

During Refactoring:

  • [ ] Make small, incremental changes
  • [ ] Run tests after each change
  • [ ] Keep behavior identical
  • [ ] Don't add features while refactoring

After Refactoring:

  • [ ] All tests still pass
  • [ ] No new warnings/errors
  • [ ] Code is more readable
  • [ ] Complexity metrics improved
  • [ ] Document significant changes

Quality Checklist

  • [ ] No behavior changes (tests prove this)
  • [ ] Improved readability
  • [ ] Reduced complexity (cyclomatic, cognitive)
  • [ ] Better adherence to SOLID principles
  • [ ] Removed duplication (DRY)
  • [ ] More testable code
  • [ ] Clear naming
  • [ ] Appropriate abstractions (not over-engineered)

Validation Script

Run ./scripts/validate-refactoring.sh to check:

  • Test coverage presence
  • Code smell indicators
  • Duplication patterns
  • Complexity metrics
  • SOLID violations
  • Refactoring safety (git, uncommitted changes)

External Resources

  • [Refactoring.Guru](https://refactoring.guru/)
  • [Martin Fowler's Refactoring Catalog](https://refactoring.com/catalog/)
  • [Working Effectively with Legacy Code](https://www.oreilly.com/library/view/working-effectively-with/0131177052/)