What this prompt does
This prompt asks the model to act as a senior engineer planning work for an AI coding agent and decompose a large refactor into Cursor-friendly tasks, each specified tightly enough to hand off without further questions. You set the [refactor] goal, the [codebase], the [max_diff] per task, and the [risk_tolerance], and it returns an ordered task list with scope, files, diff size, dependencies, and verification per task.
The structure works because the failure mode of agent-driven refactors is always the same: hand over the whole job and you get a sprawling, unreviewable diff. By forcing each task to stay under [max_diff], be independently shippable, and keep the app green, the prompt keeps every step reviewable. Explicit dependencies stop tasks running before prerequisites, and a first scaffolding task adds the new path alongside the old before removal. Specifying scope, exact files, and a one-line verification per task means you can hand each chunk to the agent without further questions, and check it landed correctly before moving on.
When to use it
- You're driving a big refactor through Cursor's agent mode.
- A single agent run produces sprawling, unreviewable diffs.
- You need each task bounded under a max diff size.
- You want explicit dependencies so nothing runs out of order.
- You need the app to stay green after every task.
- You want rollback notes calibrated to your risk tolerance.
- You want a scaffolding-first sequence that adds the new path before removing the old.
Example output
Expect a numbered task list where each task carries scope, the exact files to touch, expected diff size, dependencies, and a one-line verification step. It includes a sequencing strategy for your [codebase] that keeps the app green after every task, rollback notes per task calibrated to [risk_tolerance], and a first "scaffolding" task that adds the new path alongside the old before anything is removed. The result reads as a checklist you can feed Cursor one item at a time, verifying each before the next, so the refactor lands in reviewable pieces instead of one overwhelming diff.
Pro tips
- Keep
[max_diff]to a few hundred lines; past that, review quality falls off a cliff and the diffs stop being trustworthy. - State the
[refactor]goal concretely (e.g. migrate REST to GraphQL) so the task breakdown maps to real work. - Describe
[codebase]accurately (e.g. a Next.js + Node monorepo) so the sequencing strategy fits your structure. - Set
[risk_tolerance]honestly; low tolerance on a production app means more conservative rollback notes and smaller steps. - Insist on the scaffolding-first task so the new path exists alongside the old before any removal, keeping the app shippable.
- Use the one-line verification per task as the gate before moving on, so a broken step can't silently propagate.
