I'm the same. Every time I see people talking about explaining the project every session I'm puzzled. I've just never had to do that.

I do something similar. I've recently started having a few "starting point" files to re-explain common context (less than thirty lines per markdown file, usually) that I can point the agent at at the start of a new session, each tightly scoped to a certain domain and/or task type. That's been nice to avoid repeating myself, without the side-tracking or over-aggressive biasing-towards-previous-conversations that I've seen happen if I use long sessions or let it try to decide on its own what to pull in from larger files or trees of files. Sometimes I'll tell it to update that file based on new info from a current task, but I keep tight control over what gets pulled into task start context.

They aren't really "explaining the project" either, but more module- or task-specific preferences, hand reference pointers, or other things like "there are mixed examples of how to do certain things in this project, prefer X to Y." I use a write-everything-twice approach. After I find myself having to correct an implementation because it didn't figure out one of these things on its own from the existing code, I'll add an entry. That also avoids bloating things with "I think this is relevant" compared to "I have noticed that this is necessary."

I keep doing this because it lets me experiment with different approaches to problems without risk of it fixating on things from a previous abandoned attempt, and particularly because sometimes I'm wrong and I haven't found the agent harnesses particularly reliable at taking my word for it from a POV of "yes I know I said we need xyz earlier, but let's please entirely forget about that."

This is my usage pattern and I agree it works really well. I start almost every conversation by asking Claude to read, not write. Then once it's explored a particular slice I let it rip.

This takes a couple minutes (and I suppose I'm spending tokens each time), but sessions rarely reach compaction length and I like that I'm not trying to keep a whole separate pile of docs in sync.

In some sessions I find claude to be incredibly dumb - other times we are on the same wavelength and everything flows.

I guess I need to do some claude.md work or find other ways to prime the session so i get the good personality and not the evil twin.

I work similar, but still have architecture mds for a few selected cross cutting features. As useful for human readers as for AI.

Normally I do it exactly as you say, point at a few files, but if I know these features are involved I point at the corresponding mds instead. Its a shortcut for me to type less.

I work in a completely different manner. I have a chief of staff agent, which is one Claude code instance that orchestrates work across all my projects simultaneously with sub agents. In this way the agent helps me context switch and drive work towards everything I’m working on. I only use 1 session, I compact when necessary with todos and on file system files to track wip

I keep a plan file that records what I’m doing, how I’m doing it, and what I’ve done so far - every time I sit down to have another session, I feed Claude the plan file first, then tell it to begin on the next unchecked todo. Every time I run into something new, I tell it to add it to the todos in the plan file.

It basically takes care of itself, or at least as close as it can.

Honestly sounds like you’re not doing anything difficult. If I’m doing easy tasks it’s fine but if you need to do a major architectural project that spans 3 codebases and 2 clouds you’re gonna have a hard time without substantial context/memory management.