Given all the things I’ve learned about what works and doesn’t work, often through trial and error (and rolling back things when Cursor+Claude go off the rails), Michael’s approach was a nice improvement over where I had gotten to. So – sharing it below (with Michael’s permission).

I recommend using Claude Sonnet 4, and you can do all of this entirely in Cursor. This applies whether you are creating a greenfield project or making a substantial change to an existing one. You can repeat the process with architecture2.md, tasks2.md as needed, don’t throw them away.

Be sure to install the Puppeteer MCP so it can test in the browser.

Overview

1. Do the architecture step, see below
2. Review architecture.md, and make any changes you want – either by hand editing, asking for changes, or starting over. Particularly note if it is overcomplicating things, and ask for the simplifications you want.
3. Do the task planning step, see below
4. Review tasks.md, and make any changes you want – either by hand editing, asking for changes, or starting over. You should end up with, sa,y at least 10 steps, and often 25 or more. It will typically arrange them in phases, which is nice. Again, look for and correct excess complication.
5. Start a new chat
6. Give it the coding step prompt. It should execute the first task very cheerfully. 
7. After it is done, review it and then say “go” to get the next step. If it screwed up, you can either tell it to fix whatever it did wrong, or more usually restore checkpoint in cursor, and tell it something like “go, but use litellm for that” or whatever you need to be different.
8. Rinse and repeat!
9. Optionally, esp. If you are going to be away for a while, you can sa,y “I’m going to be afk for a bit. You can keep going on steps without waiting for me as long as both the manual and automated tests pass.” It will still stop after 25 steps or if it ignores you and runs something interactive, but it often makes a lot of progress.
10. Highly recommended: run /Generate Cursor Rules after each step

Something I haven’t tried yet, but should work well – tell it to mark what is complete in tasks.md, so you can start fresh chats periodically and not keep such a huge message history.

Architecture Step – Greenfield

I’m building a [description of your product – the more detailed the better].
[Any tech requirements, i.e. use Python for backend and React + Material-UI for the frontend. The more the better.] 
Put the full architecture in architecture.md
– File + folder structure
– What each part does
– Where the state lives, how services connect
Format this entire document in Markdown.

Architecture Step – Existing Codebase

I want to modify this codebase so that it performs [whatever].
Do all of your work consistently with the existing style and architecture.
Put the full architecture in architecture.md
– File + folder structure
– What each part does
– Where the state lives, how services connect
Format this entire document in Markdown.

Task Planning Step

Using that architecture, write a granular step-by-step plan to build the MVP.
Each task should:
– Be incredibly small + testable – it should both have unit tests that you can run, and also a manual test that you can run from the command line or using the browser tool
– Have a clear start + end
– Focus on one concern
I’ll be passing this off to an engineering LLM that’ll be instructed to complete one task at a time, allowing me to test in between. 
Save it as tasks.md.

Coding Step 

You’re an engineer building this codebase.
You’ve been given @tasks.md and @architecture.md 
– Read both carefully. There should be no ambiguity about what we’re building.
– Follow tasks.md and complete one task at a time, then run the automated tests you’ve written and use the command line or browser tool to manually test
– After each task is completed, stop. I’ll test it and review your code. If it works, commit to git and move to the next one.”
You are already in the correct directory. Build the project here. DO NOT CREATE A SUBDIRECTORY.
You have my permission to delete files IN THIS DIRECTORY without asking for approval.
BE VERY CAREFUL never to run any interactive commands in the foreground, because you’ll be stuck. For example, be sure to run the development server once, in the background with hot reloading.

Example of What A Task Step Looks Like

One step of building: