strangler-migration
Skill0 starsChanged 4 months agoMITView on GitHub
Replace a legacy module behind a facade, one vertical slice at a time, without a big-bang rewrite. Use when the user wants to migrate/replace/rewrite a large legacy component, mentions "strangler fig", or when code-archaeology's plan phase concludes a module is too large or too load-bearing to change in one PR.
In this repository11 other files it gives its agents.
- angular-enterpriseSkill
- angular-migrationSkill
- characterization-testsSkill
- claude-md-architectSkill
- code-archaeologySkill
- feature-flag-changeSkill
- frontend-review-checklistSkill
- rxjs-modernizeSkill
- session-hygieneSkill
- session-stateSkill
- tdd-loopSkill
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
- Distinctive: line 10
Do not start without: code-archaeology findings for the target module, and characterization tests pinning its current behavior (consult …
- Distinctive: line 48
Never migrate a slice without an equivalence check first — "looks equivalent" is not a substitute for /equiv-plan's exercised-input-space …
- Distinctive: line 51
Never retire the old path in the same step as the flag flip — that collapses the safety margin the whole pattern exists to provide.
- Distinctive: line 53
Never treat the facade step as optional "since we're being careful anyway" — the facade is what makes each slice revertible without …
≈ “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.
Files
<!-- owner: Muskan, added: 2026-07-16, model: claude-sonnet-5, review: quarterly -->Strangler-Fig Migration
Prerequisite
Do not start without: code-archaeology findings for the target module, and characterization tests pinning its current behavior (consult those skills first if either is missing — this skill assumes both exist).
Facade-first setup
- Introduce a facade at the module's existing public boundary (same signature, same call sites) that currently just delegates 100% of calls to the legacy implementation. Ship this alone first, with the characterization tests passing against it unchanged — proves the facade is transparent before any real migration work starts.
- Slice the module into independently-migratable vertical slices (by feature/endpoint/route, not by file) — each slice should be revertible on its own.
Per-slice checklist (repeat for every slice, in order — do not skip steps)
- Characterization tests for this slice specifically, if not already covered by the module-level suite.
- Build new: implement the slice's replacement behind the facade, untouched by the old code path yet — old and new coexist.
- Equivalence (use /equiv-plan): validate new matches old on this slice's exercised input space. Do not proceed on DIVERGENT findings without resolving them or making an explicit, logged decision to accept the behavior change.
- Flip flag: route this slice's traffic to the new implementation behind a feature flag (consult feature-flag-change skill), old path stays intact and reachable.
- Observe: state what "safe to retire old path" means for this slice (error rate threshold, time window, or explicit sign-off) before retiring anything — never retire on the same change that flips the flag.
- Retire old path for this slice only, once the observation criterion is met. Remove the flag once retirement is confirmed stable.
Rollback (per slice, not just at the end)
Each slice's flag flip must be revertible independently: flipping back to old must not require reverting other slices' migrations. State the exact revert command/flag-toggle for each slice when you flip it, not after.
Anti-patterns
- Never migrate a slice without an equivalence check first — "looks equivalent" is not a substitute for /equiv-plan's exercised-input-space comparison.
- Never retire the old path in the same step as the flag flip — that collapses the safety margin the whole pattern exists to provide.
- Never treat the facade step as optional "since we're being careful anyway" — the facade is what makes each slice revertible without touching call sites again.
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.

