3 ms·

Has anyone found a efficient way to avoid repeating the initial codebase assessment when working with large projects? There are several projects on GitHub tha

by koevet 7mo ago

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 7mo ago
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 7mo ago
  Yes this is what agent "skills" are. Just guides on any topic. The key is that you have the agent write and maintain them.
KellyCriterion 7mo ago
In Claude Web you can use projects to put files relevant for context there.
- mstkllah 7mo ago
  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.
hathawsh 7mo ago
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.
energy123 7mo ago
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.
chickensong 7mo ago
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.
verma6uc 7mo ago
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

by koevet 7mo ago

jsmith99 7mo ago

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 7mo ago
Yes this is what agent "skills" are. Just guides on any topic. The key is that you have the agent write and maintain them.

KellyCriterion 7mo ago

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

mstkllah 7mo ago
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.

hathawsh 7mo ago

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.

energy123 7mo ago

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.

chickensong 7mo ago

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.

verma6uc 7mo ago

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