Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Stop Claude Code from forgetting everything

github.com

Post reply on HN
Print view View original

231–240 of 241 posts

Re: Show HN: Stop Claude Code from forgetting everything

#231

Post by dnautics »

AndyNemmity wrote: post #217
dnautics wrote: post #191

Earlier quoted context omitted.

yeah but a skill without the mcp server is just going to be super inefficient at certain things. again going to my example, a skill to do a dependency graph would have to do a complex search. and in some languages the dependency might be hidden by macros/reflection etc which would obscure a result obtained by grep how would you do this with a skill, which is just a text file nudging the llm whereas the MCP's server g…

A skill is not just a text file nudging the llm. You group scripts and programming to the skill, and the skill calls it.

that seems token inefficient. why have the llm do a full round trip. load the skill which contains the potentially hundreds of lines code then copy and paste the code back into the compiler when it could just run it?

not that i care too too much about small amounts of tokens but depleting your context rapidly seems bad. what is the positive tradeoff here?

Re: Show HN: Stop Claude Code from forgetting everything

#232

Post by AndyNemmity »

troupo wrote: post #223
AndyNemmity wrote: post #215

Earlier quoted context omitted.

Skill are md files, but they are not just that. They are also scripts. That's what adding things are. You can make a skill that is just a prompt, but that misses the point of the value. You're packaging the tool with the skill, or multiple tools to do a single thing.

In the end it's still an .md file pointing to a script that ends being just a prompt for the agent that the agent may or may not pick up, may or may not discover, may or may not forget after context compaction etc. There's no inherent magic to skills, or any fundamental difference between them and "just feeding in different prompts and steps". It literally is just feeding different prompt and steps.

I find in my experience that it's trivial to have the skill systematically call the script, and perform the action correctly. This has not been a challenge to me.

Also, the pick up or not pick up, or discover or may not discover is solved as well. It's handled by my router, which I wrote about here - https://vexjoy.com/posts/the-do-router/

So these are solved problems to me. There are many more problems which are not solved, which are the interesting space to continue with.

Re: Show HN: Stop Claude Code from forgetting everything

#233

Post by AndyNemmity »

dnautics wrote: post #230
AndyNemmity wrote: post #216

Earlier quoted context omitted.

But the skill includes the scripts to do things. So in my nano banana image generation skill, it contains a python script that does all the actual work. The skill just knows how to call the python script. We're attaching tools to the md files. This is at the granular level of how to hammer a nail, how to use a screw driver, etc. And then the agent, the handyman, has his tool box of skills to call depending on what he…

lets say i'm in erlang. you gonna include a script to unpack erlang bytecode across all active modules and look through them for a function call? oorrr... have that code running on localhost:4000 so that its a single invocation away, versus having the llm copypasta the entire script you provided and pray for the best?

The LLM doesn't copy the script, it runs it.

But for sure, there are places it makes sense, and there are places it doesn't. I'm arguing to maximully use it for places that make sense.

People are not doing this. They are leaving the LLM to everything. I am arguing it is better to move everything possible into tools that you can, and have the LLM focus only on the bits that a program doesn't make sense for.

Re: Show HN: Stop Claude Code from forgetting everything

#234

Post by AndyNemmity »

dnautics wrote: post #231
AndyNemmity wrote: post #217

Earlier quoted context omitted.

A skill is not just a text file nudging the llm. You group scripts and programming to the skill, and the skill calls it.

that seems token inefficient. why have the llm do a full round trip. load the skill which contains the potentially hundreds of lines code then copy and paste the code back into the compiler when it could just run it? not that i care too too much about small amounts of tokens but depleting your context rapidly seems bad. what is the positive tradeoff here?

I don't understand. The Skill runs the tools. In the cases there are problems where you can have programs replace the LLM, I think we should maximully do that.

That uses less tokens. The LLM is just calling the script, and getting the response, and then using that to continue to reason.

So I'm not exactly following.

Re: Show HN: Stop Claude Code from forgetting everything

#235

Post by lkbm »

AndyNemmity wrote: post #99
lkbm wrote: post #87

Earlier quoted context omitted.

I'm curious how those replace this? I've barely used either, and would love to hear more.

Okay, Claude.md is an md file with instructions. Agents are an md file with instructions. Skills are an md file with instructions. Commands are.. you get the point. We're just dealing with instructions. Claude.md is handled by Claude Code. It is forgotten almost entirely often when the context fills. Okay, what is an agent? An agent is basically a Claude.md file, but you make it extremely granular. So it only has ins…

A little. Thanks for the detailed reply. But I wouldn't expect a smaller, more targeted Claude.md would make a big difference. My impression is that we're filling up the context less with Claude.md than with the session work: back and forth about the specific task, Claude's chain-of-thought as it does that, the relevant sections of code, etc. That's what this is trying to compact and reference, iiuc.

What I'd think would help, would be doing things in smaller chunks: an agent to do this small subtask, another to do that small subtask, and the parent task context only grows with the sub-agents reporting back, not with their chain-of-thought.

Could be I should have a much bigger, more detailed Claude.md. Mine tend to be small project overviews and a list of TODOs, not that different from README.md: https://github.com/lkbm/sideways_math/blob/main/CLAUDE.md

Re: Show HN: Stop Claude Code from forgetting everything

#236

Post by AndyNemmity »

lkbm wrote: post #235
AndyNemmity wrote: post #99

Earlier quoted context omitted.

Okay, Claude.md is an md file with instructions. Agents are an md file with instructions. Skills are an md file with instructions. Commands are.. you get the point. We're just dealing with instructions. Claude.md is handled by Claude Code. It is forgotten almost entirely often when the context fills. Okay, what is an agent? An agent is basically a Claude.md file, but you make it extremely granular. So it only has ins…

A little. Thanks for the detailed reply. But I wouldn't expect a smaller, more targeted Claude.md would make a big difference. My impression is that we're filling up the context less with Claude.md than with the session work: back and forth about the specific task, Claude's chain-of-thought as it does that, the relevant sections of code, etc. That's what this is trying to compact and reference, iiuc. What I'd think w…

It does make a big difference in the sense that the less you tell it about things that aren't relevant to it's task, the better it performs.

This has been found in all sorts of variations, and is accepted. It's not just my word, it's the standard understanding. But also, it's true in my experience.

You also limit the session work when you are offloading to agents, which are calling skills. So it does do that as well.

But that's what we're talking about, having agents do things in smaller chunks. Maybe I didn't explain that clearly enough?

It's just a complex topic. It's hard to cover everything. But yet, that's part of the idea. We're making context very specific to the task, and cutting things up into smaller chunks with dedicated context windows only for that task.

I almost completely ignore Claude.md - there are very few rules I want every subtask to know about.

the main system is for cordination, of the many agents with their own dedicated Claude.mds which call their own skills with their own dedicated instructions.

It's like Russian dolls. Now, I do use much, much MUCH larger Agent mds than anyone else. I've been doing this for 10 months, and I believe it's the correct way to do it.

I intend to write a blog post on it, it's a topic in it's own part.

Even your small Claude.md - I would have in several files. The Typescript agent is the only one that needs to know about the Typescript details. This is the kind of thing I mean.

Re: Show HN: Stop Claude Code from forgetting everything

#238

Post by edmundsparrow »

I've been manually copying responses between chats when I hit token limits, and I'm wondering - have you considered a multi-AI consensus approach instead of persistent memory?

The idea: multiple AIs (Claude, GPT, Gemini, Grok) brainstorm simultaneously and produce one agreed response. This might solve the context problem more elegantly because:

- No token limit anxiety - you get comprehensive answers upfront - Better quality through AI cross-validation - The consensus answer naturally becomes your context - Simpler to implement - just parallel API calls vs memory tree management

Just curious if you've explored this direction or if there's a reason the memory persistence approach works better for your use case?

Re: Show HN: Stop Claude Code from forgetting everything

#239

Post by edmundsauto »

AndyNemmity wrote: post #218
edmundsauto wrote: post #214

Earlier quoted context omitted.

Would you share an overview of how it works? Sounds interesting

Perhaps I can release it as a standalone github skill, and then do a blog post on it or something. I'm just also working on real projects as well, so a lot of my priority is focused on new skills building, and not worrying about managing the current ones I have as github repos.

That would probably be a lot of work for little gain. Would you be open to asking Claude to summarize your approach and just put it into a paste? I'm less interested in specific implementations and more about approaches, what the tradeoffs are and where it best applies.

Re: Show HN: Stop Claude Code from forgetting everything

#240

Post by dnautics »

AndyNemmity wrote: post #234
dnautics wrote: post #231

Earlier quoted context omitted.

that seems token inefficient. why have the llm do a full round trip. load the skill which contains the potentially hundreds of lines code then copy and paste the code back into the compiler when it could just run it? not that i care too too much about small amounts of tokens but depleting your context rapidly seems bad. what is the positive tradeoff here?

I don't understand. The Skill runs the tools. In the cases there are problems where you can have programs replace the LLM, I think we should maximully do that. That uses less tokens. The LLM is just calling the script, and getting the response, and then using that to continue to reason. So I'm not exactly following.

what you are proposing is functionally equivalent to "wrapping an mcp in a cli" which is what I mentioned in my root comment.
Post reply on HN