agentleFS
cwinvestmentscwinvestments/memstack/skills/development/refactor-planner/SKILL.md

memstack-development-refactor-planner

Skill425 starsChanged 5 months agoMITView on GitHub

Use this skill when the user says 'refactor', 'refactoring plan', 'code cleanup', 'reduce duplication', 'simplify code', 'tech debt', 'god class', 'tight coupling', or needs to systematically improve existing code. Identifies targets, assesses risk, and builds incremental execution plans. Do NOT use for writing new features or database migrations.

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 4 are distinctive, and 0 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.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When this skill activates, output:

    line 13
  2. Distinctive:

    If the user hasn't provided details, ask:

    line 43
  3. Distinctive:

    Start with LOW risk, HIGH value targets (quick wins)

    line 129
  4. Distinctive:

    Never refactor HIGH risk targets without >80% test coverage

    line 132

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Refactor Planner: Planning systematic code improvement...

Identifies code smells, assesses refactoring risk, selects appropriate patterns, and builds incremental execution plans with rollback strategies and verification checkpoints.

Activation

When this skill activates, output:

Refactor Planner: Planning systematic code improvement...

Then execute the protocol below.

Context Guard

ContextStatus
User says "refactor", "refactoring plan", "code cleanup"ACTIVE
User says "tech debt", "god class", "tight coupling", "reduce duplication"ACTIVE
User wants to improve existing code structure without changing behaviorACTIVE
User wants to write a new featureDORMANT: use Feature Spec
User wants to change database schemaDORMANT: use Migration Planner

Common Mistakes

MistakeWhy It's Wrong
"Big bang rewrite"Rewriting everything at once introduces cascading failures. Incremental changes are safer and shippable.
"Refactor without tests"No test coverage = no safety net. Add characterization tests BEFORE touching code.
"Refactor and add features simultaneously"Mixing behavior changes with structural changes makes bugs impossible to isolate. Separate commits.
"No measurable goal""Clean up the code" is vague. Define metrics: reduce file from 800 to 200 lines, eliminate 5 duplicate blocks, etc.
"Skip the risk assessment"A function called by 47 files is higher risk than a utility used in 2. Assess blast radius first.

Protocol

Step 1: Gather Refactoring Context

If the user hasn't provided details, ask:

  1. Target: what code needs refactoring? (file, module, class, or system)
  2. Pain point: what's the specific problem? (hard to modify, duplicated, slow, confusing)
  3. Test coverage: does the target code have tests? (yes, partial, none)
  4. Constraints: any deadlines, frozen APIs, or deployment concerns?
  5. Language/framework: what tech stack?

Step 2: Identify Code Smells

Scan the target code for these smell categories:

Bloaters (too big):

SmellDetectionSeverity
Long methodFunction >30 lines or >3 levels of nestingMedium
Large class / God objectClass >300 lines or >10 public methodsHigh
Long parameter listFunction takes >4 parametersMedium
Primitive obsessionRaw strings/numbers instead of domain typesLow
Data clumpsSame group of variables passed together repeatedlyMedium

Couplers (too connected):

SmellDetectionSeverity
Feature envyMethod uses another class's data more than its ownMedium
Inappropriate intimacyClasses access each other's private internalsHigh
Message chainsa.getB().getC().getD().doThing(): chain >2 deepMedium
Middle manClass delegates nearly everything to another classLow

Dispensables (unnecessary):

SmellDetectionSeverity
Dead codeUnreachable code, unused variables, commented-out blocksLow
Duplicate codeSame logic in 2+ places (exact or structural)High
Speculative generalityAbstractions, interfaces, or config for cases that don't existMedium
Lazy classClass does too little to justify its existenceLow

Change preventers (hard to modify):

SmellDetectionSeverity
Divergent changeOne class changed for many different reasonsHigh
Shotgun surgeryOne change requires edits across many filesHigh
Parallel inheritanceCreating a subclass in one hierarchy requires one in anotherMedium

Code smell report:

## Code Smell Report: [Target]

| # | Smell | Location | Severity | Lines Affected |
|---|-------|----------|----------|---------------|
| 1 | [Smell name] | [file:line] | High/Med/Low | [X] |
| 2 | [Smell name] | [file:line] | High/Med/Low | [X] |
| ... | | | | |

**Summary:** [X] smells found ([X] high, [X] medium, [X] low)
**Estimated scope:** [X] files, [X] lines affected

Step 3: Assess Risk

For each refactoring target, evaluate:

Risk matrix:

FactorLow RiskMedium RiskHigh Risk
Dependents0-2 callers3-10 callers10+ callers
Test coverage>80% covered40-80% covered<40% covered
ComplexitySimple extractionCross-file changesArchitectural change
ReversibilityEasy to revertRequires migrationData format changes
Blast radiusSingle fileSingle moduleCross-module

Risk score per target:

| Target | Dependents | Coverage | Complexity | Reversibility | Blast Radius | Risk Score |
|--------|-----------|----------|-----------|---------------|-------------|------------|
| [File/Class] | [X] callers | [X]% | Low/Med/High | Easy/Med/Hard | File/Module/System | Low/Med/High |

Risk-based ordering rule:

  1. Start with LOW risk, HIGH value targets (quick wins)
  2. Then MEDIUM risk targets (with tests added first)
  3. HIGH risk targets last (with comprehensive test coverage first)
  4. Never refactor HIGH risk targets without >80% test coverage

Step 4: Select Refactoring Patterns

Match each smell to the appropriate pattern:

Extraction patterns:

PatternUse WhenBefore → After
Extract MethodLong method, duplicated logic blockInline code → Named function
Extract ClassGod class, divergent changeOne class → Two focused classes
Extract InterfaceTight coupling, testing difficultyConcrete dependency → Interface + implementation
Extract VariableComplex expression, magic numbersif (a > 86400 && b < 3) → if (isExpired && belowRetryLimit)

Simplification patterns:

PatternUse WhenBefore → After
Replace Conditional with PolymorphismLong switch/if chains on typeSwitch statement → Strategy pattern
Replace Parameter with MethodParameter that callee can computecalc(getX(), getY()) → calc() (fetches internally)
Introduce Parameter ObjectLong parameter list, data clumpsfn(x, y, z, w) → fn(config)
Replace Temp with QueryTemp variable used once after calculationtemp = calc(); use(temp) → use(calc())

Structural patterns:

PatternUse WhenBefore → After
Move Method/FieldFeature envy, misplaced responsibilityMethod in wrong class → Move to correct class
Inline ClassLazy class, middle manUseless wrapper → Merge into user
Replace Inheritance with CompositionFragile base class, deep hierarchyextends Base → has Base with delegation
Introduce FacadeComplex subsystem, shotgun surgeryDirect subsystem calls → Facade mediates

Pattern selection table:

| # | Smell | Pattern | Target | Estimated Effort |
|---|-------|---------|--------|-----------------|
| 1 | [Smell] | [Pattern] | [file:line] | [X] hours |
| 2 | [Smell] | [Pattern] | [file:line] | [X] hours |

Step 5: Build Execution Plan

Structure the refactoring into safe, incremental phases:

Phase template:

## Refactoring Plan: [Target]

### Phase 0: Safety Net (do this first)
- [ ] Add characterization tests for current behavior
- [ ] Verify all existing tests pass
- [ ] Create a feature branch: `refactor/[target-name]`
- [ ] Document current behavior snapshot

### Phase 1: Quick Wins (low risk, high value)
**Target:** [Smell → Pattern]
- [ ] Step 1: [Specific action]
- [ ] Step 2: [Specific action]
- [ ] Verify: Run tests, confirm no behavior change
- [ ] Commit: `refactor: [description]`

### Phase 2: Core Improvements (medium risk)
**Target:** [Smell → Pattern]
- [ ] Step 1: [Specific action]
- [ ] Step 2: [Specific action]
- [ ] Verify: Run tests, confirm no behavior change
- [ ] Commit: `refactor: [description]`

### Phase 3: Structural Changes (higher risk)
**Target:** [Smell → Pattern]
- [ ] Step 1: [Specific action]
- [ ] Step 2: [Specific action]
- [ ] Verify: Run full test suite + manual smoke test
- [ ] Commit: `refactor: [description]`

### Verification Checkpoints
After each phase:
1. All tests pass (unit + integration)
2. No behavior change (same inputs → same outputs)
3. Metrics improved (lines reduced, complexity lowered)
4. Code review approved (if team)

Effort estimation guide:

PatternTypical EffortRisk Level
Extract Variable5-15 minVery Low
Extract Method15-30 minLow
Introduce Parameter Object30-60 minLow
Extract Class1-3 hoursMedium
Replace Conditional with Polymorphism2-4 hoursMedium
Replace Inheritance with Composition3-6 hoursHigh
Extract Interface + Dependency Injection2-5 hoursMedium-High
Architectural restructure (module boundaries)1-3 daysHigh

Step 6: Define Rollback Strategy

For each phase, document how to reverse:

## Rollback Strategy

| Phase | Rollback Method | Time to Revert |
|-------|----------------|---------------|
| Phase 1 | `git revert [commit]` | <5 min |
| Phase 2 | `git revert [commit]` | <5 min |
| Phase 3 | `git revert [commit]` + re-run migrations if applicable | <15 min |

**Abort criteria (stop refactoring if):**
- Test failures that can't be explained within 30 minutes
- Performance regression >10% on critical paths
- Deadline pressure requires shipping current work
- Discovery of architectural issues requiring design discussion

Step 7: Measure Results

Define before/after metrics:

## Refactoring Metrics

| Metric | Before | After | Change |
|--------|--------|-------|--------|
| Lines of code (target) | [X] | [X] | -[X]% |
| Cyclomatic complexity | [X] | [X] | -[X]% |
| Number of methods | [X] | [X] | [+/-X] |
| Average method length | [X] lines | [X] lines | -[X]% |
| Duplicate code blocks | [X] | [X] | -[X] |
| Test coverage | [X]% | [X]% | +[X]% |
| Number of dependencies | [X] | [X] | -[X] |

Output Format

# Refactoring Plan: [Target]

## Code Smell Report
[From Step 2, smells identified with severity and location]

## Risk Assessment
[From Step 3, risk matrix for each target]

## Pattern Selection
[From Step 4, matched patterns with estimated effort]

## Execution Plan
[From Step 5, phased plan with verification checkpoints]

## Rollback Strategy
[From Step 6, revert method per phase + abort criteria]

## Success Metrics
[From Step 7: before/after targets]

Completion

Refactor Planner: Complete!

Target: [Target name]
Smells found: [X] ([X] high, [X] medium, [X] low)
Phases: [X]
Estimated effort: [X] hours
Risk level: [Overall Low/Medium/High]
Patterns applied: [List]

Next steps:
1. Add characterization tests for current behavior (Phase 0)
2. Create feature branch: refactor/[target-name]
3. Execute Phase 1 (quick wins) and verify tests pass
4. Continue through phases, committing after each
5. Measure before/after metrics and document improvements

Level History

  • Lv.1: Base: 4 code smell categories (bloaters, couplers, dispensables, change preventers) with 16 specific smells, 5-factor risk matrix, 12 refactoring patterns in 3 groups (extraction, simplification, structural), phased execution plan template, rollback strategy with abort criteria, before/after metrics tracking. (Origin: MemStack Pro v3.2, Mar 2026)

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.