[koevet]

Has anyone found a efficient way to avoid repeating the initial codebase assessment when working with large projects?

There are several projects on GitHub that attempt to tackle context and memory limitations, but I haven’t found one that consistently works well in practice.

My current workaround is to maintain a set of Markdown files, each covering a specific subsystem or area of the application. Depending on the task, I provide only the relevant documents to Claude Code to limit the context scope. It works reasonably well, but it still feels like a manual and fragile solution. I’m interested in more robust strategies for persistent project context or structured codebase understanding.

[jsmith99]

Whenever I build a new feature with it I end up with several plan files leftover. I ask CC to combine them all, update with what we actually ended up building and name it something sensible, then whenever I want to work on that area again it's a useful reference (including the architecture, decisions and tradeoffs, relevant files etc).

[Sammi]

Yes this is what agent "skills" are. Just guides on any topic. The key is that you have the agent write and maintain them.

[verma6uc]

This is the exact problem we built Glue to solve. Maintaining markdown files per subsystem works but breaks down as the codebase evolves — the docs drift from reality within weeks. Glue keeps a live, queryable map of the codebase that updates as code changes, so you're not repeating the assessment or trusting stale docs. Happy to share more if useful — getglueapp.com

[energy123]

For my longer spec files, I grep the subheaders/headers (with line numbers) and show this compact representation to the LLM's context window. I also have a file that describes what each spec files is and where it's located, and I force the LLM to read that and pull the subsections it needs. I also have one entrypoint requirements file (20k tokens) that I force it to read in full before it does anything else, every line I wrote myself. But none of this is a silver bullet.

[hathawsh]

That sounds like the recommended approach. However, there's one more thing I often do: whenever Claude Code and I complete a task that didn't go well at first, I ask CC what it learned, and then I tell it to write down what it learned for the future. It's hard to believe how much better CC has become since I started doing that. I ask it to write dozens of unit tests and it just does. Nearly perfectly. It's insane.

[chickensong]

I'm interested in this as well.

Skills almost seem like a solution, but they still need an out-of-band process to keep them updated as the codebase evolves. For now, a structured workflow that includes aggressive updates at the end of the loop is what I use.

[KellyCriterion]

In Claude Web you can use projects to put files relevant for context there.

[mstkllah]

And then you have to remind it frequently to make use of the files. Happened to me so many times that I added it both to custom instructions as well as to the project memory.