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

191–200 of 241 posts

Re: Show HN: Stop Claude Code from forgetting everything

#191

Post by dnautics »

austinbaggio wrote: post #108
dnautics wrote: post #88

Earlier quoted context omitted.

i don't understand this mcp/skill distinction? one of the mcps i use indexes the runtime dependency of code modules so that claude can refactor without just blindly grepping. how would that be a "skill"? just wrap the mcp in a cli? fwiw this may be a skill issue, pun intended, but i can't seem to get claude to trigger skills, whereas it reaches for mcps more... i wonder if im missing something. I'm plenty productive…

In our experience, a lot of it is feel and dev preference. After talking to quite a few developers, we've found the skill was the easiest to get started with, but we also have a CLI tool and an MCP server too. You can check out the docs if you'd prefer to try those - feedback welcome: https://www.ensue-network.ai/docs#cli-tool

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 goes out and does things.

Re: Show HN: Stop Claude Code from forgetting everything

#193

Post by saberience »

Do we really need another vibe-coded LLM context/memory startup?

Do the authors have any benchmarks or test to show that this genuinely improved outputs?

I have tried probably 10-20 other open source projects and closed source projects purporting to improve Claude Code with memory/context, and still to this date, nothing works better than simply keeping my own library of markdown files for each project specification, markdown files for decisions made etc, and then explicitly telling Claude Code to review x,y,z markdown files.

I would also suggest to the founders, don't found a startup based on improving context for Claude Code, why? Because this is the number 1 thing the Claude Code developers are working on too, and it's clearly getting better and better with every release.

So not only are you competing with like 20+ other startups and 20+ other open-source projects, you are competing with Anthropic too.

Re: Show HN: Stop Claude Code from forgetting everything

#194

Post by sdoering »

saberience wrote: post #193

Do we really need another vibe-coded LLM context/memory startup? Do the authors have any benchmarks or test to show that this genuinely improved outputs? I have tried probably 10-20 other open source projects and closed source projects purporting to improve Claude Code with memory/context, and still to this date, nothing works better than simply keeping my own library of markdown files for each project specification,…

This. Exactly this. Even relatively well working tools (from my experience and for my project types) like Agent OS are no guarantee, that Claude will not go on a tangent, use the "memory files" the framework tells it to use.

And I agree with your sentiment, that this is a "business field" that will get eaten by the next generations of base models getting better.

Re: Show HN: Stop Claude Code from forgetting everything

#196

Post by dimitri-vs »

brigandish wrote: post #58
dimitri-vs wrote: post #35

Earlier quoted context omitted.

I'm in Claude Code 30+ hr/wk and always have a at least three tabs of CC agents open in my terminal. Agree with the other comments: pretty much running vanilla everything and only the Playwright MCP (IMO way better than the native chrome integration) and ccstatusline (for fun). Subagents can be as simple as saying "do X task(s) with subagent(s)". Skills are just self @-ing markdown files. Two of the most important th…

How can you - or any human - review that much code?

TBH I'm not building "production grade" apps depended on by hundreds of thousands of users - our clients want to get to a live MVP as fast as possible and love the ability to iterate quickly.

That said, it's well know that Anthropic uses CC for production. You just slow things down a bit, spend more time on the spec/planning stage and manually approve each change. IMO the main hurdle to broader Claude Code adoption isn't a code quality one, it's mostly getting over the "that's not how I would have written it" mindset.

Re: Show HN: Stop Claude Code from forgetting everything

#197

Post by gbnwl »

christinetyip wrote: post #182
gbnwl wrote: post #79

I'm not sure how many HN users frequent other places related to agentic coding like the subreddits of particular providers, but this has got to be the 1000th "ultimate memory system"/break-free-of-the-context-limit-tyranny! project I've seen, and like all other similar projects there's never any evidence or even attempt at measuring any metric of performance improved by it. Of course it's hard to measure such a thing…

This is fair, many memory projects out there boil down to better summaries or prompt glue without any clear way to measure impact. One thing I’d clarify about what we’re building is that it’s not meant to be “the best memory for a single agent.” The core idea is portability and sharing, not just persistence. Concretely: - you can give Codex access to memory created while working in Claude - Claude Code can retrieve c…

> That’s the part that’s hard (or impossible) to do with markdown files or tool-local memory.

I'm confused because every single thing in that list is trivial? Why would Codex have trouble reading a markdown file Claude wrote or vice versa? Why would multiple agents need their own copy of the markdown file instead of just referring to it as needed? Why would it be hard to share specific files with teammates or collaborators?

Edit - I realize I could be more helpful if I actually shared how I manage project context:

CLAUDE.md or Agents.md is not the only place to store context for agents in a project, you can just store docs at any layer of granularity you want. What's worked best for me is to:

1. Have a standards doc(s) (you can point the agents to the same standards doc in their respective claude.md/agents.md)

2. Before coding, have the agent create implementation plans that get stored in to tickets (markdown files) for each chunk of work that would take about a context window length (estimated).

3. Work through the tickets and update them as completed. Easy to refer back to when needed.

4. If you want you can ask the agent to contribute to an overall dev log as well, but this gets long fast. Is useful for agents to refer to the last 50 lines or so to immediately get up to speed on "what just happened?", but so could git history.

5. Ultimately the code is going to be the real "memory" of the true state, so try to organize it in a way that's easy for agents to comb through (no 5000 lines files that agents have trouble trying to carefully jump around in to find what they need without eating up their entire context window immediately).

Re: Show HN: Stop Claude Code from forgetting everything

#198

Post by blks »

brigandish wrote: post #58
dimitri-vs wrote: post #35

Earlier quoted context omitted.

I'm in Claude Code 30+ hr/wk and always have a at least three tabs of CC agents open in my terminal. Agree with the other comments: pretty much running vanilla everything and only the Playwright MCP (IMO way better than the native chrome integration) and ccstatusline (for fun). Subagents can be as simple as saying "do X task(s) with subagent(s)". Skills are just self @-ing markdown files. Two of the most important th…

How can you - or any human - review that much code?

They don’t, they just push garbage, someone else quickly looks over it (or asks another llm to review for him), and merges.

Re: Show HN: Stop Claude Code from forgetting everything

#200

Post by christinetyip »

gbnwl wrote: post #197
christinetyip wrote: post #182

Earlier quoted context omitted.

This is fair, many memory projects out there boil down to better summaries or prompt glue without any clear way to measure impact. One thing I’d clarify about what we’re building is that it’s not meant to be “the best memory for a single agent.” The core idea is portability and sharing, not just persistence. Concretely: - you can give Codex access to memory created while working in Claude - Claude Code can retrieve c…

> That’s the part that’s hard (or impossible) to do with markdown files or tool-local memory. I'm confused because every single thing in that list is trivial? Why would Codex have trouble reading a markdown file Claude wrote or vice versa? Why would multiple agents need their own copy of the markdown file instead of just referring to it as needed? Why would it be hard to share specific files with teammates or collabo…

You’re right that reading the same markdown file is trivial, that’s not the hard part.

Where it stopped being trivial for us was once multiple agents were working at the same time. For example, one agent is deciding on an architecture while another is already generating code. A constraint changes mid-way. With a flat file, both agents can read it, but you’re relying on humans as the coordination layer: deciding which docs are authoritative, when plans are superseded, which tickets are still valid, and how context should be scoped for a given agent.

This gets harder once context is shared across tools or collaborators’ agents. You start running into questions like who can read vs. update which parts of context, how to share only relevant decisions, how agents discover what matters without scanning a growing pile of files, and how updates propagate without state drifting apart.

You can build conventions around this with files, and for many workflows that works well. But once multiple agents are updating state asynchronously, the complexity shifts from storage to coordination. That boundary - sharing and coordinating evolving context across many agents and tools — is what we’re focused on and what an external memory network can solve.

If you’ve found ways to push that boundary further with files alone, I’d genuinely be curious - this still feels like an open design space.

Post reply on HN