can you explain a bit more what do you mean by burning down? and what do you use .md files for? Documenting the code?
Define a feature in detail (using trascription) -> Get o3 or Gemini 2.5 pro to break it down into very small testable tasks. -> review this -> then paste into a tasks.md file -> write and architecture.md file or similar for any additional context needed. -> then prompt Cursor to work through tasks.md step by step.
This keeps it on track, with the whole feature defined from the outset.
But eventually... it will try to ignore the dockerfile and setup up locally, create multiple .env files, write code with placeholders, ignore a files it's just created and written...
It's impossible to get it back on track - it gets into a debug loop of making things worse rather than getting back on track.
It's just cursor's system prompt problem. they just need time to "tame" the model after release.
for now, I just make sure that in every chat thread i have "DO NOT WRITE ANY DOCUMENTATION OR TEST OR ANYTHING THAT WASN'T EXPLICITLY ASKED. STAY LEAN"
But i sort of reached the point where I don't mind claude going off the rails a bit. Like restricting it with .md and constantly updating those guardrails sounds like more of a burden than help.
its just the prompt problem. try reading the chat and every time you see it doing excessive shit stop the chat and slap it on wrist saying "never create .env i already have it, you just don't have access, etc".
also, sounds obvious, but don't forget to create new conversations often. the "ignore a files it's just created" sounds like context window overload. 200k window for a new model sounds like a crime from anthropic
Tell it to remove the task from the file after it's done, then do a commit. That way if it screws up at some point you can checkout the last good commit and start from there in a new chat.