What this prompt does
This prompt has the model act as a senior Angular engineer and migrate a module-based feature to standalone components plus signals, returning working before/after code rather than pseudocode. You provide the [angular_version], the [feature] to migrate, your [current_state] approach, and any [constraints], and it returns the conversion, signal-based state, effect boundaries, resource() loading, a migration order, and a list of common traps.
The structure works because signal migrations are where teams either modernize cleanly or quietly break change detection. By converting components and routes to standalone with route-level providers, replacing [current_state] with signals and computed derivations, and moving side effects into effect() boundaries, the prompt keeps the change disciplined. The migration order from step 5 is deliberately smallest-safe-steps so the app stays green between each. Returning before/after code for a representative component means you see the exact shape of the change, and the called-out traps tell you where these migrations usually go wrong before you hit them yourself.
When to use it
- A legacy module-based feature needs to move to standalone components and signals.
- You want to avoid a big-bang rewrite and migrate incrementally.
- You're replacing BehaviorSubject-style state with signals and computed.
- You need side effects moved cleanly into
effect()boundaries. - You want
resource()for async loading with loading, error, and empty states. - You want the app to stay shippable between every step.
- You want a pattern you can repeat across other module-based features later.
Example output
Expect before/after code for one representative component and its route config. The "before" shows the module-based feature with [current_state]; the "after" shows standalone components with route-level providers, signal-based state with computed derivations, side effects in effect() with cleanup notes, and resource() handling loading/error/empty states. Alongside the code you get the smallest-safe-steps migration order and a list of common traps to avoid, so you can sequence the work in small steps to keep the app shippable at every point and sidestep the change-detection breakages that usually derail these migrations partway through.
Pro tips
- Insist on step 5's incremental order — migrating signals all at once is how you end up debugging effects for a week.
- Set
[current_state]accurately (e.g. a service with BehaviorSubjects) so the before/after actually maps to your code. - Pick a contained
[feature]like a product list with filters for the first migration, then repeat the pattern. - Set
[angular_version]to your target so the output uses APIs your version actually has. - Watch the called-out traps: effect overuse, signal writes inside computed, and stale providers are the common ways these migrations break.
- Honor your
[constraints](e.g. app must stay shippable between steps) so the migration order respects them.
