Item — HN Reader

maybe a bit counter-intuitive but:

I found that removing

  - system prompt
  - skills
  - agents.md
  - mcps

+ reducing tools to just 1 (sh)

gives better results than having 'more' of them

(e.g. look at these traces to see more vs less in action:)

https://smolenv.com/t/nested-template-includes-60636/

not saying the right context does not help

(it definitely does!, but it's not trivial to provide the right context)

2 comments

This is the right direction (Anthropic removing 80% of the system prompt https://claude.com/blog/the-new-rules-of-context-engineering...)

However what I wonder how we make these decisions on what to remove. Certainly some subset of the skills / AGENTS.md / prompt / tools do actually help agent performance, the problem is in identifying those, throwing away the rest, and validating that this didn't actually hurt the agent performance

'better results' in terms of what though? A benchmark, or code that I would actually click "approve" on in a pull request scenario?

apologies, I should have clarified the 'better' claim

  - same task result (passed)
  - finished faster
  - fewer tokens, less cost
  - fewer requests for inference
  - fewer tool calls
  - less peak RAM

Yes, my question is directed around how you are determining "task result." Is this measuring whether the code works, or whether it is maintainable?

As with human-powered coding, we read code far more frequently than we write it. It's worth spending a little extra (time|tokens) during authorship to make future maintenance feasible.

My CLAUDE.md, memories, and skills are all about either (a) adherence to project standards and guidelines, (b) product decisions which impact future code, and (c) instructions on how to prototype and work in my environment.

Removing these instructions would mean more turns with the AI to get the desired result.

You don't have to remove them - you can move things that are not important to every prompt to aseparate small docs that are referenced in agents.md with ,"when needed, reference these files:" and list them in form * relpath - content summary" or similar.

. When you want those instructions to be followed, mentiont them in your prompt. "Test this following procedures on docs/test.md". (I've found I don't have to do that extra instruction in al cases depending on model)

That's what MEMORY.md and subdirectory-specific CLAUDE.md does.

Aren't subdirectory specific Claude files layered in on top? Seems like more required content when the direction I'm suggesting is more like lazy-loading.

They load only when operating on files in that directory. i.e. Lazy loading?

For example, I have one in my schema migrations directory that explains how to write migrations with appropriate concern for forwards- and backwards-compatibility in our deployment model.

great point, progressive disclosure is a good pattern for context management

in this case there was a hidden grader that checked if the implementation was correct (because that was the easiest thing to check), all 3 agents cleared this hurdle in all 9 runs

I agree, next it makes sense to try more open ended tasks + have humans (and/or multiple models) grade the runs and their results