zlacker

>>latchk+(OP)
I went through the whole readme first and kept wondering what problem the system aims to address. I understood that it is a distributed issue tracker. But how can that lead to a memory upgrade? It also hints at replacing markdown for plans.

So is the issue the format or lack of structure which a local database can bring in?

>>wowami+Pv
LLMs famously don't have a memory - every time you start a new conversation with the you are effectively resetting them to a blank slate.

Giving them somewhere to jot down notes is a surprisingly effective way of working around this limitation.

The simplest version of this is to let them read and write files. I often tell my coding agents "append things you figure out to notes.md as you are working" - then in future sessions I can tell them to read or search that file.

Beads is a much more structured way of achieving the same thing. I expect it works well partly because LLM training data makes them familiar with the issue/bug tracker style of working already.

>>simonw+mw
I’ve been using beads for a few projects and I find it superior to spec kit or any other form of structured workflow.

I also find it faster to use. I tell the agent the problem, ask them to write a set of tasks using beads, it creates the tasks and it creates the “depends on” tree structure. Then I tell it to work on one task at a time and require my review before continuing.

The added benefit is the agent doesn’t need to hold so much context in order to work on the tasks. I can start a new session and tell it to continue the tasks.

Most of this can work without beads but it’s so easy to use it’s the only spec tool I’ve found that has stuck.

>>qudat+EH
Is there a good way to use beads without pushing your .beads dir upstream?