Skilllibrary migration-pack-builder

Generate structured migration plans with inventory, risk-ranked sequence, rollback procedures, and acceptance criteria for major upgrades or framework migrations. Use when upgrading major dependencies (React 17→18, Python 3.9→3.12), migrating frameworks (Express→Fastify, CRA→Vite), or scoping 'modernize the codebase' initiatives. Do not use for patch-level dependency updates or greenfield projects.

install
source · Clone the upstream repo
git clone https://github.com/merceralex397-collab/skilllibrary
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/merceralex397-collab/skilllibrary "$T" && mkdir -p ~/.claude/skills && cp -r "$T/01-package-scaffolding/migration-pack-builder" ~/.claude/skills/merceralex397-collab-skilllibrary-migration-pack-builder && rm -rf "$T"
manifest: 01-package-scaffolding/migration-pack-builder/SKILL.md
source content

Migration Pack Builder

Turns "we need to upgrade X" into a methodical execution plan.

Procedure

1. Create migration inventory

Identify all affected surfaces:

## Inventory: [Migration Name]

### Direct Dependencies
| Package | Current | Target | Breaking Changes |
|---------|---------|--------|------------------|
| [name]  | [ver]   | [ver]  | [list]           |

### Affected Files
- [path pattern] ([N] files) — [why affected]

### Integration Points
- CI/CD: [changes needed]
- Testing: [framework upgrade required?]
- Build tooling: [changes needed]

2. Risk assessment per component

Risk LevelCriteriaExamples
HighCore business logic, payment, auth, data persistencePayment processing, auth flow
MediumUI components, utilities with many dependentsShared component library
LowDev tooling, test utilities, isolated featuresLinter config, test helpers

3. Define migration sequence

Order by: dependencies first, then risk (low → high):

### Migration Sequence
1. [ ] Update build tooling (low risk, unblocks others)
2. [ ] Migrate test utilities (enables validation of later stages)
3. [ ] Low-risk leaf components (build confidence)
4. [ ] Core utilities (high dependency count)
5. [ ] High-risk business logic (with extra validation)

4. Define rollback procedure per stage

### Rollback: Stage N
- Git: `git revert HEAD~N..HEAD`
- Dependencies: `npm ci` from lockfile at tag `pre-stage-N`
- Verification: `npm test && npm run e2e`

5. Define acceptance criteria

### Acceptance Criteria
- [ ] All existing tests pass (or intentional updates documented)
- [ ] No type errors introduced
- [ ] Bundle size delta < 5%
- [ ] Performance metrics maintained
- [ ] Manual QA of critical user flows

Output contract

# Migration Pack: [Name] — [From] → [To]

## Summary
- Scope: [N] files, [N] packages
- Estimated effort: [X] days
- Risk level: [High/Medium/Low]

## Inventory
[tables from step 1]

## Migration Sequence
[ordered stages with checkboxes]

## Rollback Procedures
[per-stage rollback]

## Acceptance Criteria
[checklist]

## Known Issues & Workarounds
[documented blockers and solutions]

Failure handling

  • Circular dependencies in migration order: Identify cycle; create compatibility shim to break it
  • No test coverage for affected code: Add characterization tests BEFORE migration
  • Breaking change not documented upstream: Check GitHub issues and changelogs; document findings
  • Partial migration blocks progress: Always use feature branches with atomic commits per stage