Please store new `plan.md` files in repo
M
Marcin Kubica
option to have plans in git repo! yes!
Gamepad Coder
💯% agree.
At a bare minimum
an immediate
low-effort-high-impact
workaround:add a Windsurf vscode command to view the current chat's
plan.md
- then ctrl+shift+p: >plan
- can quickly navigate to a command like Windsurf: View current chat's plan.md
Why:
- echoing OP: because plan.mdis not in a traditional root dir like<project or workspace>/.windsurf/it's enormously difficult to find a given thread'splan.mdif you accidentally close it or if you switch chats.
G
George Lerner
I work on a plan with Cascade, and approve it.
- No random switching plans: Cascade randomly jumps to its own plan, and I have to prompt Cascade not just "update my plan" but I have to give full file name.
- No plan clutter: Dozens of plan files, with random file names, all to try to get the same small feature in one file working; that isn't helpful.
- No panel clutter: Cascade panel is cluttered with it altering its internal plan with everything it learns searching for a bug; that makes it hard for me to actually know what it is changing and why.
So, keep its internal musings in silent mode unless I click something to show them; named plans go in my project folder (in docs/plans would be best); switch plans when I say to.
W
William Diaz Pabón
Nowadays, almost for every new chat, a new plan.md document is created and that's not that valuable, I would think that those plans should evolve into an architectural document local to the project.
For example, if I have a project already advanced, I tell Windsurf to analyze everything, and build an MD document with the definitions of the project's architecture and complement it with the best practices of software development focused on the framework I am using in that project, plus SOLID, more clean code and that the document is well structured so that it is the absolute truth for decision-making in the new code.
This should make it automatic and you should always consult this document first so that you can make the most accurate decisions and not get lost in the architectural design of the project we are developing.
What do they think?
Gamepad Coder
William Diaz Pabón I've actually found when the current
plan.md
gets too long, the SWE-1 agent will begin to ignore important items. And starting a new thread, prompting to inject necessary context into a new plan.md
, and then having it start with that refreshed plan.md
-> it typically performs much better and will self heal out of ruts. YMMV -- really depends on the type of task and how much high level / low level context it currently needs.Mike Stromme
I agree with this but for now what I do is let it create the plan in the user directory and then when I like it I as chat to save the plan in my current workspace. It seems like if you let it copy the file there it doesn't lose track of it if you do a save as. I've only done this a couple of times though so experiences may vary.
Kenneth Brooks
Agree that this should be in the project/repo, not in some magic windsurf folder.
When working in an enterprise the plan for the repo IS the plan. All developers should be able to see it and act on it.
Dbsk Dbsk
yeah, i also like it can be in project, i have seperate plan.md for diffferent project and i don't want them to interface, now ws force me mixed them, it's not good.
in windsurf it's just a tiny option, global(default)/project
I
Ivan Dorna
mmmhh someone has learned from the data sent... the planning method is extraordinarily similar to our modus operandi that has always been with AI and these are the operations that we are going to do pre task and post windsurfing and all the other editors with AI, yes, as the comment says, it makes absolutely more sense to put the plan.md in the repository in the directory you want. So the trigger should be on the name/role of the file not on the keyword and position.
M
Marcos Zapata
then users on workspaces with more than one repo, will have an issue with that. Plus, the plan is to keep track between you and your ai, not sure if I want my team to pull the plan.md and see how I get things done (albeit we can gitignore it), we have project management apps for that. Just my two cents,
Happy coding!
I
Ivan Dorna
Marcos Zapata in fact... we have 40 repositories and it's unusable unless you move it, since it's been 100% our modus operandi, always with other file names but managed in the same way with our prompt framework.
Roy Wright
You can easily do a save as. The working plan.md has a lot of churn as cascade works thru the list. Maybe the step by step is what you want in your repo, maybe just the original plan.
That said, I have had cascade create a plan from a prompt, saved it, went to a new project and started the new conversation with “execute the plan in plan.md”. Mostly worked (it did try to skip one step). As you can tune a plan to a known state, vs hoping the LLM randomizer is nice to your prompt, I see the potential of having a library of cultivated plans.
Ian Mayo
Roy Wright - I'm ok with that 'churn' being under VCS - it's a project artefact, after all.
Load More
→