What this prompt does
This prompt plans and executes an AI-assisted migration from [source_framework] to [target_framework] for an application described by [app_description], with [file_count] files and [test_count] tests. Rather than a vague "rewrite it" request, it defines a seven-step workflow that moves the codebase piece by piece while preserving behavior.
The structure works because it sequences risk sensibly. A compatibility audit maps every [source_framework] dependency to its [target_framework] equivalent up front, flagging dead-ends before you are committed. A per-component template ports one [component_categories] element at a time, carrying its props and tests across so behavior is preserved. Dedicated steps convert routing from [source_routing] to [target_routing], state from [source_state] to [target_state], and tests from [source_test_framework] to [target_test_framework], each mapped one-to-one. A validation step generates a feature checklist from the source and verifies each feature exists in the target, and a tracking spreadsheet keeps status visible across the whole migration.
When to use it
- You are moving a frontend between frameworks and want a safe, incremental plan.
- You need to know early which dependencies have no
[target_framework]equivalent. - You want components ported one at a time with their tests, not all at once.
- You need routing, state, and tests migrated with explicit one-to-one mappings.
- You want a feature-parity check between the old and new versions.
- You need a tracking sheet to manage a migration across many files and reviewers.
Example output
Expect a migration plan built from reusable prompts rather than a one-shot conversion. It begins with a compatibility audit table that maps each [source_framework] dependency to its [target_framework] equivalent and flags packages with no direct match. Then comes a component-migration template you apply iteratively across your [component_categories], each port carrying its props and tests so behavior is preserved. Dedicated prompts handle routing conversion from [source_routing] to [target_routing], state-management mapping from [source_state] to [target_state], and test conversion from [source_test_framework] to [target_test_framework]. A validation checklist generated from the source verifies feature parity in the target, and a tracking spreadsheet with file path, status, reviewer, test status, and notes keeps the whole effort visible.
Pro tips
- Run the compatibility audit first and resolve every flagged dependency before porting code — a dead-end found halfway through is the most expensive failure mode.
- Keep the per-component template tight: port one
[component_categories]element plus its tests, review, then move on. - Migrate tests alongside each component, not at the end, so you always have a behavioral check on what you just ported.
- Set
[source_state]and[target_state]precisely; a sloppy state mapping is where subtle behavior changes hide. - Use the validation step on every component, since framework idioms differ enough that visual parity can mask missing behavior.
- Keep the tracking sheet current; on a
[file_count]-file migration it is the only reliable view of what is done.
