I’ve had generally good results with this approach (I’m on project #3 using this method).
I haven't done extensive experiments, but I have noticed anecdotal benefits to asking the LLM how they want things structured as well.
For example, for complex multi-stage tasks I asked Claude Code how best to communicate the objective and it recommended a markdown file with the following sections: "High-level goal", "User stories", "Technical requirements", "Non-goals". I then created such a doc for a pretty complex task then asked Claude to review the doc and ask any clarifications. I then answer any questions (usually 5-7) and put them into a "Clarification" section. I have also added a "Completion checklist" section that I use to ensure that Claude follows all of the rules in my subdirectory "README.md" files (I have one for each major sub-section of code, like my service layer, my router layer, my database, etc). I usually go and do 2-3 rounds of Claude asking questions and me adding to the "Clarification" section and then Claude is satisfied and ready to implement.
The bonus of this approach is I now have a growing list of the task specifications checked into a "tasks" directory showing the history of how the code base came to be.
At this point, I typically do an LLM-readme at the branch level to document both planning and progress. At the project level I've started having it dump (and organize) everything in a work-focused Obsidian vault. This way I end up with cross-project resources in one place, it doesn't bloat my repos, and it can be used by other agents from where it is.
In there I have generic advice on project management (use `gh` and Github issues for todo lists) and language-specific guidance in separate files, like which libraries to use etc.
Then I have a common prompt template for different agents that tells them to look there for specific technology choices and create/update their own WHATEVER.md file in the repo.
Gemini-cli is pretty efficient for creating specs and doesn't run out of context. With Context7 it can pull up API specs into the documentation it creates and with Brave API it can search for other stuff.
After it's done, I can just tell Claude to make a step by step plan based on the specs and create Github issues for them with the appropriate labels.
Clear context, and get Claude working on the issues one by one.
I'm just using vscode edit mode, so I expect I'm being too simple, mostly as I haven't found out how to make agent mode work with front and back end in separate docker containers.
Would you mind sharing a bit of insight into how you've configured your environment such that you get good results?
https://github.com/jerpint/context-llemur
It’s MCP/CLI friendly , and wraps git around a context: folder, so you can super easily load context anywhere using: “ctx load” and ask LLMs to update and save context as things move along
give nia a try and use it on any docs, very curious to hear ur feedback