It destroys the context for readers, making the thread worse for everyone.
I would love to see other setups, like what MCP, hooks, sub-agents, commands, etc.
She has newer posts on sub agents
Agents have their own context and can be useful for tasks that can be parallelized, which is a minority of tasks. How are they critical to better performance for you?
Let's consider context. At some level the more context you have is good. At some level, the more irrelevant context you have is bad.
Okay. We have at top level of context, a hook that forces a system prompt on every action.
Next level we have a ./claude/CLAUDE.md then we have the project level CLAUDE.md then we have a possible not required agent setup then we have the instructions you give it
We know that CLAUDE.md gets lost in the context, at any level. The system prompt level hooks don't.
Why does the CLAUDE.md get lost? Why are we losing ability with a longer context.
The problem is irrelevant context to the action. The Documentation agent doesn't require the Golang modernization rules. The Golang agent, doesn't require the planing coordinator rules.
So the question I asked myself last weekend was, what is the experience if you split the contexts to only the required information for the task.
I did head to head battles with agents, reading in the information, versus contextual specific information. The agents with context specific destroyed the competition. Like it was another world.
So then I ran head to head tests on the type of information. Etc etc. My current setup is the best level achieved in those tests.
So my argument is that removing the context that is entirely irrelevant for the agent improves performance dramatically.
But I'm one person doing tests... it's true for me. Maybe it's not true for others. People have to explore the conception and determine that.
I can only tell you what has worked best for me, and for me, it's like a model jump in performance improvements.
I didn't release it as open source or anything, just sharing. I don't want to take questions concerning it so I can focus on moving it forward.
Today's goal is to try to build self healing agents that automatically fix the problems they encounter so they only happen once, automating a manual process I successfully use.
Perhaps if that works out well, that is something releasable I can do in a real way as opposed to paste bin.
The more I focus the less I have time to read and experiment O want to finish it. What are your sources and how are you balancing it ?
MCP servers and the rest have not provided the type of gains sub-agents have. Hooks and subagents actually provide tangible value. Enough that it's changed my structure entirely to be tool focused, and not output focused.
Maybe it does have some valuable content but I will just close it.
That is a bit over the top, but the core statement kind of stands.
This is like 99% of my CC interactions working on top of a well structured codebase and it just works perfectly for almost any task I throw at it.
Why would you need that?
> CLAUDE.md is a special file that Claude automatically pulls into context when starting a conversation.
https://www.anthropic.com/engineering/claude-code-best-pract...
That CLAUDE.md file that they've posted is also HUGE - Anthropic themselves recommend keeping it on the more concise side. If you need more, consider just creating dedicated subagents for "UI/UX reviewer", "search", etc.
Like "for guidance on Go library selection refer to docs/go.md"
That way the main file stays compact.
However posts like this is valuable for new people to get a basic understanding of how these tools could be used in a very simple, beginner friendly, setup.
At the moment they burn a investor money to gain customers by giving us free tools and cheap LLMs.
That will end at some point.
- I wouldn’t outsource my brain to CC when it comes to checking CC’s output. Very mixed results in my experience, and it might discourage further exploration/thinking if you’ve already performed the checklist CC has given you (satisficing).
- Slash commands are the idiomatic way to memoize often used prompts, I wonder why author put them in CLAUDE.md?
- I’m also a bit skeptical that, aside from strict rules CC needs to follow, the encouragements/enchantments for writing good code author put in CLAUDE.md really work. But who knows.
- I DO like the caveats section at the end a lot. This is probably the most important piece of the article, when it comes to large codebases. Never just accept the first draft. Review everything with high suspicion and bend the output to your own style and taste. Otherwise, you‘re pushing legacy code.
