When tackling new features, I’ve found this workflow to be effective:
The key is to keep your scope minimal and modular. By maintaining updated context documents, Cursor can better understand the project’s evolution and mitigate the dreaded circular death.
Love this concept.
What’s an example prompt you’d give Cursor to create such a ‘context document’ ? Should this context document be for the new feature you’re developing, or for the existing codebase which you’re modifying ? Would one keep this context document under source control along with your code ?
In this use case, does Context = Scope?
Are you talking about a Scope document or something else? I use scope documents for features broadly, and sometimes use a context-history document when I find the AI is getting trapped in a loop.
I use a scope document by prompting like this.
“{I explain the feature that I want built}
Create a file called feature.md and include a plain language summary of the feature I’ve asked you to build. Describe the functionality and business logic in detail. Then create a checklist of the components required to bring this to life, as well as a list of the files that they will be in. Break the requirements of the features and tests into logical steps.”
I start with something like this, then after the file is created and I review/tweak it, I’ll usually start a fresh Composer agent (so it doesn’t undo my changes), and prompt it like this:
“I want you to create the feature detailed in ‘feature.md’ work through the requirements step by step, and update the checklist as you go. Do not make any changes to feature.md beyond marking the checklist as complete without my approval. Let me know when you’ve completed each step”
I use review the code between each step. This keeps the agent from getting side-tracked and allows me to review the changes in manageable chunks. Sometimes I will ask it to write tests for each step and iterate on the tests until everything is passing. This works really well with YOLO mode, which I have set to allow the agent to run tests but do little else.
Yes - was looking for what folks are putting into such a document, and how they’re prompting to get it generated.
Sounds like your feature.md document is being used for two purposes, one is to describe the feature in detail / keep track of what parts been completed, and two is to maintain continuity for said feature across potentially multiple chat/composer windows (sessions).
I have not yet used such an approach… and hence have occasionally seen a composer agent ‘Un-doing’ some (sub) feature that it did previously. Or perhaps this was due to using a second composer agent that didn’t have the context of the first.
Thanks!