Verified against GitHub Copilot Edits · 2026-07-27
Plan a multi-file migration before Copilot Edits touches a single file
A migration brief for Copilot Edits that forces a dependency-ordered, file-by-file plan and a one-file pilot checkpoint before any multi-file rewrite starts.
The prompt
Ready to copy — highlighted parts are example details you can swap.
I want to migrate the class-component + Redux connect() pattern to function components with hooks and the existing useAppSelector/useAppDispatch hooks using Copilot Edits across multiple files. Before editing anything, produce a plan — do not start changing files until I approve it. SCOPE Every component under components/dashboard/, roughly 14 files. MUST NOT BREAK The memoized selectors in dashboard components must not re-render on every store update — that performance behavior is load-bearing on the live dashboard. PLAN FORMAT 1. List every file in scope and, for each, the specific change it needs — not "update as needed." 2. Order the files so a shared or foundational file (types, config, a base class) is migrated before the files depending on it, and say why that order avoids a broken intermediate state. 3. Name one file to migrate first as a pilot, and how I will know from that single file whether the overall approach is right before the rest are touched. 4. For each item under MUST NOT BREAK, name which specific file's migration could threaten it, and how the plan avoids that. After I approve the plan, migrate only the pilot file from step 3 and stop. Show me that diff before continuing to the rest.
Customize the highlighted detailsoptional — the prompt above already works
Why this works
Copilot Edits, the multi-file editing mode in Copilot Chat, can propose changes across several files in one pass, which is exactly the mechanism a migration needs but also exactly where an unscoped migration goes wrong — a model asked to migrate X to Y across a codebase tends to touch files in whatever order it encounters them, which can leave a dependent file migrated before the shared type or config it relies on, producing a broken intermediate state that is hard to bisect afterward. Forcing an explicit dependency-aware ordering, foundational files before dependents, mirrors how a careful human would sequence the same migration and gives you something to sanity-check before any code moves. Naming a single pilot file and stopping after it turns a large multi-file migration into a cheap checkpoint: if the approach is wrong, there is one file's diff to revert, not twenty. The must-not-break section, mapped explicitly to the specific file threatening each item, exists because a generic don't break anything instruction gives Copilot Edits nothing to check itself against — a named risk tied to a named file is something the plan step can actually reason about before a single line changes.
What you get back
Plan (excerpt): 1. Migrate dashboard/types.ts first (shared prop types, no component logic) — foundational, nothing depends on it changing behavior. 2. Migrate DashboardSummaryCard.tsx as the pilot: smallest component using the pattern, low traffic, easy to verify in isolation. 3. Risk check: memoized selector behavior in DashboardSummaryCard.tsx currently relies on connect()'s shallow-equal check — the hooks version must use useAppSelector with an equivalent selector, not a naive useSelector(state => state.dashboard), or it will re-render on every store update, violating the must-not-break constraint.
Verified against
GitHub Copilot Edits Copilot Edits 1.260 (VS Code, multi-file) · 2026-07-27
Changelog
- 2026-07-27 — Initial publish, verified against Copilot Edits 1.260 (VS Code).
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
