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.
I can’t imagine this being worth optimizing. The issue is never that Claude can’t figure out what the projects is about…
Am I missing something or does this project not solve a problem most regular people have?
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.
I’ve basically never edited a skill or memory myself. I make the LLM do it as part of the /handoff skill before I clear a session. That also includes pruning existing skills/memories and resolving any drift.
Even the /handoff skill was written by the model…
It's funny because with so many different implementations of /handoff, I wonder if anyone has benchmarked handoff-and-resume to figure out what the best performance implementation looks like.
I also imagine that varies by model.
Mine are project-specific, which is a bit annoying since I’d like it to be global but there are some project-specific additions. Maybe I’ll (ask Claude to) refactor that to be more composable.
It should be a first class feature of the harness, tbh. It kind of is with the /compact [focus] parameter but this is coarse and leaves no record. I find keeping the handoff files in the repo to be useful for historical context and later debugging.
> Filling context with what you think the model needs adds nothing and possibly just inflates context which is harmful.
The solution that I've developed is, let the agent figure things out efficiently, without inflating the context. I have what I call a smart repo that better explains this at
https://github.com/gitsense/smart-ripgrep
The basic idea is, when the agent does a ripgrep it gets back files + matching lines + context.
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.
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.
There are bunch of tools to manage context or fix what Claude does wrong. They may be popular because non software engineers want to improve their workflows, like you mentioned.
But are they really working instead of making it worse? Are there any tests or real case studies done by users not tool's author? From my experience, removing from context works more often then adding.
Git commit?
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 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.