Verified against Cursor · 2026-07-25
Use Cursor's whole-codebase context to migrate a state-management library site-wide, not file by file
A brief for a large, cross-cutting library migration that leans on Agent mode's long-context codebase understanding to first produce a complete inventory of usage patterns before touching a single file, so the migration plan accounts for every variant of how the old library is actually used, not just the common case.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Migrate this codebase from Redux with redux-thunk, v4.2 to Zustand v5. This touches many files with several different usage patterns, not one consistent pattern repeated everywhere — do not assume the first few examples you see represent every usage. CURRENT LIBRARY AND VERSION Redux with redux-thunk, v4.2 TARGET LIBRARY AND VERSION Zustand v5 KNOWN USAGE PATTERN VARIANTS TO EXPECT connect() HOC wrapping class components; useSelector/useDispatch hooks in function components; thunk action creators dispatched from event handlers; middleware reading store state directly outside React. MIGRATION MAPPING — old pattern to new pattern useSelector(selectFn) becomes useStore(selectFn) directly. Thunk action creators become plain async functions calling store.getState()/store.setState(). connect() HOCs need manual conversion to hooks since Zustand has no HOC equivalent. STAGE 1 — FULL INVENTORY Before migrating anything, search the entire codebase for every usage of Redux with redux-thunk, v4.2 and group them by which variant they match from USAGE_VARIANTS above. Report the count per variant and flag any usage that doesn't cleanly match a known variant — those are the ones most likely to need a judgment call rather than a mechanical swap. STAGE 2 — MIGRATE BY VARIANT, NOT BY FILE Migrate one variant at a time across every file it appears in, rather than one file at a time across every variant it happens to contain. This keeps each pass mechanically consistent and makes it obvious if a variant's migration mapping doesn't actually work uniformly once applied broadly. STAGE 3 — HANDLE THE UNMATCHED CASES For every usage flagged as not matching a known variant in Stage 1, propose a specific mapping and flag it for review rather than silently applying your best guess at the same confidence as a known-variant migration. STAGE 4 — VERIFY Run the full test suite after each variant pass, not just at the end, so a regression is traceable to the specific variant migration that caused it. Report the final state as: total usages migrated, broken down by variant, plus the list of judgment calls made in Stage 3 with reasoning for each.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
A codebase-wide library migration is exactly the kind of task where Agent mode's ability to hold and search a large indexed context matters more than in a single-file edit, because the actual difficulty isn't translating one usage of the old library into the new one — that part is often mechanical — it's that a mature codebase almost never uses a state library one consistent way everywhere, and a migration plan built from the first handful of examples the model happens to open will confidently apply the wrong mapping to every variant it never looked at closely. Requiring a full inventory before any file changes, grouped explicitly by USAGE_VARIANTS, forces that discovery to happen up front as a checkable list rather than being discovered piecemeal as each new pattern breaks the previous pass's mapping partway through the migration. Migrating by variant across every file rather than by file across every variant is the specific sequencing choice that makes Stage 1's inventory actually pay off: doing one variant at a time means a mapping that turns out to be subtly wrong reveals itself after a handful of files, not after all of them, and the fix applies uniformly to every remaining instance of that variant instead of needing to be re-discovered file by file. Explicitly separating unmatched usages into their own Stage 3 review, rather than letting them get silently folded into whichever known variant they most resemble, matters because a usage that doesn't cleanly fit any known pattern is, by definition, the case the migration mapping was never actually designed for — applying a known mapping to it anyway at the same confidence as a real match is how a migration introduces a subtle behavior change in exactly the code nobody thought to scrutinize, precisely because it looked similar enough to something already handled.
Verified against
Cursor 2.2 · 2026-07-25
Changelog
- 2026-07-25 — Initial publish, verified against Cursor 2.2 Agent mode on a Redux-to-Zustand migration.
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
