agentleFS
d-o-hubd-o-hub/github-template-ai-agents/.agents/skills/migration-refactoring/SKILL.md

migration-refactoring

Skill2 starsChanged 10 days agoMITView on GitHub

Automate complex code migrations and refactorings with safety patterns. Use this skill when a dependency upgrade forces source changes, when migrating frameworks (React class→hooks, Flask→FastAPI), modernizing languages (Python 2→3), or performing large-scale refactories — even if they just say "migrate this" or "refactor the whole thing". Includes breaking change analysis, automated fix application, rollback strategies, and cross-file dependency tracking. Not for static-analysis, code-review-assistant, or routine patch/minor/CVE bumps (use dependency-upgrades).

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    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:

    Map dependencies: - Create a dependency graph of cross-file relationships

    line 27
  2. Distinctive:

    Validate at each checkpoint: - Test compilation, run tests, verify functionality

    line 41
  3. Distinctive:

    Document changes: - Update docs, changelogs, ADRs

    line 42
  4. Distinctive:

    Run full test suite: - Verify nothing broken

    line 47
  5. Distinctive:

    Performance testing: - Ensure no regressions

    line 48

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

Migration & Refactoring

Systematic approach to complex code migrations with safety guardrails and rollback capabilities.

When to Use

  • Dependency upgrades that force source changes - major bumps with breaking APIs; routine patch/minor/CVE bumps go to dependency-upgrades
  • Framework migrations - React class→hooks, Flask→FastAPI, Django→DRF, etc.
  • Language modernizations - Python 2→3, JavaScript→TypeScript
  • Large-scale refactoring - Cross-file changes requiring consistency
  • Database schema evolution - Migrations with data transformation
  • Monorepo decomposition - Extracting services from monoliths

Core Workflow

Phase 1: Analysis

  1. Identify scope - What files, modules, and dependencies are affected?
  2. Map dependencies - Create a dependency graph of cross-file relationships
  3. Find breaking changes - Analyze changelogs, migration guides, deprecation warnings
  4. Assess risk - Flag high-risk changes (public APIs, critical paths)

Phase 2: Planning

  1. Create migration plan - Ordered sequence of changes
  2. Define checkpoints - Intermediate states that compile/work
  3. Design rollback strategy - How to revert if issues arise
  4. Estimate effort - Time and complexity assessment

Phase 3: Execution

  1. Execute in phases - Apply changes incrementally
  2. Validate at each checkpoint - Test compilation, run tests, verify functionality
  3. Document changes - Update docs, changelogs, ADRs
  4. Commit incrementally - Each checkpoint is a commit

Phase 4: Validation

  1. Run full test suite - Verify nothing broken
  2. Performance testing - Ensure no regressions
  3. Code review - Human validation of changes
  4. Production rollout - Deploy with monitoring

Migration Patterns

Pattern 1: Gradual Migration

Old API → Compatibility Layer → New API → Remove Old

When: Cannot change all call sites at once

Pattern 2: Feature Flags

if (useNewImplementation) {
  return newImplementation();
} else {
  return oldImplementation();
}

When: High-risk changes needing rollback capability

Pattern 3: Strangler Fig

Monolith → Proxy → New Service
              → Old Monolith

When: Decomposing monoliths incrementally

Pattern 4: Parallel Implementation

Old System (read-only) → Data Sync → New System (write)

When: Zero-downtime migrations with data changes

See references/migration-patterns.md for detailed implementations.

Breaking Change Analysis

Checklist for Upgrades

  • Review CHANGELOG for breaking changes
  • Check deprecation warnings in current version
  • Identify removed/renamed APIs
  • Find changed default behaviors
  • Note environment/dependency changes
  • Review migration guide if available
  • Search for known issues in community

Common Breaking Changes

CategoryExamples
API Removalfunction removed()
Signature Changesfunc(a, b) → func(a, b, c)
Default Changesencoding='utf-8' → encoding=None'
Dependency DropsDropped Python 3.8 support
Return Type Changeslist → generator

Cross-File Dependency Tracking

Dependency Graph Elements

  • Imports/includes - File A imports File B
  • Inheritance - Class A extends Class B
  • Interface implementations - Class implements Interface
  • Function calls - Function in A calls function in B

Tools by Language

  • Python: pydeps, importlab
  • JavaScript/TypeScript: dependency-cruiser, madge
  • Java: jdeps, classycle
  • Go: godepgraph
  • Rust: cargo-deps

See references/dependency-analysis.md for detailed usage.

Safety Patterns

Snapshot Testing

# Before migration: capture expected outputs
save_snapshot(test_output, "v1_expected.json")

# After migration: compare
assert_matches_snapshot(actual_output, "v1_expected.json")

Property-Based Testing

# Verify invariants hold post-migration
@given(st.data())
def test_migration_preserves_properties(data):
    old_result = old_implementation(data)
    new_result = new_implementation(data)
    assert old_result.property == new_result.property

Canary Deployments

  1. Deploy to 1% of traffic
  2. Monitor error rates, latency
  3. Gradually increase to 100%
  4. Rollback if issues detected

See references/safety-patterns.md for more patterns.

Rollback Strategies

StrategyBest forExample
Git RevertSmall, isolated migrationsgit revert <migration-commit>
Feature Flag DisableGradual rolloutsUSE_NEW_PARSER = False
Database RollbackSchema changes with data lossALTER TABLE users DROP COLUMN ...

See references/rollback-strategies.md for platform-specific guides.

Examples

React Class to Hooks: componentDidMount/componentWillUnmount → useEffect, componentDidUpdate → useEffect with deps, this.state → useState, this.props → destructured.

Python 2 to 3: 2to3 -w --output-dir=src_py3 src/ then fix imports, print, string handling. See references/language-migrations.md.

Quality Checklist

  • Breaking changes documented
  • Rollback procedure tested
  • All dependencies mapped
  • Checkpoints defined and validated
  • Test coverage maintained or improved
  • Performance regression testing done
  • Code review completed
  • Documentation updated

See Also

  • static-analysis — Linter triage and fix workflows
  • code-review-assistant — PR review workflow
  • dependency-upgrades — Routine patch/minor/CVE version bumps

Rationalizations

RationalizationReality
"We'll migrate everything at once in one big PR"Big-bang migrations create untestable changesets with no safe rollback point.
"The old version still works, no rush to migrate"Unmaintained dependencies accumulate CVEs and block critical security patches.
"Automated tests are enough validation"Automated tests catch regressions; human review catches design and UX regressions.

Red Flags

  • Starting a migration without a documented rollback strategy
  • Migrating multiple major dependencies in a single commit
  • Skipping checkpoint validation between migration phases

References

  • references/migration-patterns.md - Detailed pattern implementations
  • references/dependency-analysis.md - Cross-file dependency tracking
  • references/language-migrations.md - Framework migration guides

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.