There are many other posts here which agree with you. Filling context with what you think the model needs adds nothing and possibly just inflates context which is harmful.

A good method seems to be only make a skill or memory when the LLM gets something wrong, or if you actually observe it's always doing the same step and you can get the model to the same place with less tokens.

What I've finally come to understand is that there is a large amount of people who are now able to write and use software through claude and coding agents. Those people have different needs than more traditional software engineers who have more knowledge because even best llms often need steering, correction, and refactoring suggestions when iterating on code and it's fine to let it lose context because exactly like you said, you tell it to read file and then have to regurgitate the understanding so you can correct or validate it before continuing.

For those where the code is almost entirely a black box and cannot easily recover when something goes wrong. They are much more keen on this context management and planning because recovering from derailments is much harder (and takes longer) because its often a conversation with llm to try to recover to where they were before.

Depending on the scale of the project and the complexity of the specific thing you need to work on, it's advantageous to bring specific context into the session instead of hoping the model will connect the right dots.

I specifically have instructions for claude explaining the purpose of the project in pretty much all repos. Just a simple PROJECT.md is enough - and referenced from AGENTS.md

There I usually lay out stuff like "this is a personal greenfield project" and "don't bother with multi-user support" etc. Or Claude will default to creating something WEBSCALE for a simple tool that won't run outside of my local LAN-only Proxmox setup. And that'll also skip massive database migration support for a project that's 3 days old - the agent doesn't know that. I'm just dropping it on the project after a full memory wipe.

>I might be missing out on something but I never had to explain my project. Just give it a task, or if you really want to, type it quickly, then you are good to go.

This means its changes will either be out of alignment with the overall project and its "style" and goals, or it waste tokens re-getting to know the basics about the project each time.

No third case.

I guess that depends on the kind of project, how common the intent is, how self contained, etc.