gastownhall/beads

I’ve been using Steve Yegge’s Beads[1] lightweight issue tracker for this type of multi-agent context tracking. I only run a couple of agents at a time, but with Beads you can create issues, then agents can assign them to themselves, etc. Agents or the human driver can also add context in epics, and I think you can have perpetual issues which contain context too. Or could make them as a type of issue yourself, it’s a very flexible system. [1] https://github.com/steveyegge/beads

Claude is... unfortunetly... that much better. They really know how to use the tools that integrate into CLI that just makes the flow so much better. The only extra stuff I am doing now is beads. https://github.com/steveyegge/beads I was using speckit and ralph-loop but think anthropic baked in that ralph-loop. Basically a dumb while true until you break with the condition.

I spec out everything in excruciating detail with spec docs. Then I actually read them. Finally, we create granular tasks called "beads" (see https://github.com/steveyegge/beads ). The beads allows us to create epics/tasks/subtasks and associated dependency structure down to a granular bead, and then the agents pull a "bead" to implement. So, mostly we're either creating spec docs and creating beads or implementing, quality checking, and testing the code created from an agent implementing a bead. I can say this produces better code than I could write after 10yrs of focused daily coding myself. However, I don't think "vibe coders" that have never truly learned to code, have any realistic chan…

I have not tried Gas Town yet, but Steve's beads https://github.com/steveyegge/beads (used by Gas Town) has been a game-changer, on the order of what claude code was when it arrived.

There're multiple task solutions for Claude or other llms that let it define tasks, add implementation notes and (crucially) add sub-tasks and dependencies. I'm using Beads ( https://github.com/steveyegge/beads ) and I think it really improves the outcome; especially for larger projects.

…give it the go-ahead to do the next item or two or three. I've wondered how this is implemented, how OpenCode sets up and picks up on this structuring. Beads formalizing that a bit more is tempting. I also deeply deeply enjoy that Beads is checked in. With both Aider and OpenCode, there's a nice history. But it's typically not checked in. OpenCode 's history in particular isnt even kept in the project directory, and can be quite complex with multiple sessions and multiple agents all flying around. Beads, as a strategy to record the work & understand it better, is also very tempting. Would love to see deeper OpenCode + Beads integration.

I’ve done spec driven development using a bunch of markdown files. That works fine but what I have found really works is using beads: https://github.com/steveyegge/beads I’m letting the agent help me draft the specs anyway and I found that the agent is a lot more focused when it can traverse a task tree using beads. It’s the one spec or planning tool that I find really helps get things done without a bunch of intervention. Another technique I employ is I require each task to be TDD. So every feature has two tasks: write tests that fail, implement feature and don’t notify me until tests complete. Then I ask the agent to tell me how to review the task and require I review every task before …

…ths" thing, but we'll see! > But what I’m also really yearning for is having a distributed asynchronous/offline-first code review flow built right in. It's not code review, it's issue tracking, but I've been using https://github.com/steveyegge/beads this week, and I think it might be the first "put your issues in your repo" system I actually enjoy. It says it's built for AI stuff, but like, you don't have to use AI with it.

That is why a minimal framework[1] that allows me to understand the core immutable loop, but to quickly experiment with all these imperative concepts is invaluable. I was able to try Beads[1] quickly with my framework and decided I like it enough to keep it. If I don't like it, just drop it, they're composable. [0]: https://github.com/aperoc/toolkami.git [1]: https://github.com/steveyegge/beads

Better to keep tasks in a separate repo imo, or at least make sure they aren't committed. I always follow one rule: looking at the git history should tell me what each change did, and the commit message alone should be enough to understand what actually changed. If you mix tasks with code changes, you will just confuse your future self. Moreover, you can set up something like beads to handle task delegation and status updates for your agents. https://github.com/gastownhall/beads

I looked into beads but I didn't see a way to make it work any better than fossil, and fossil does more stuff. My typical setup is to use the repo as a working directory, the tickets for todo, wiki/forum for conversation. There is also a chat interface, but I haven't tried that with agents yet. But I love fossil for this. You can create users for all of the agents (or agent roles). The CLI for fossil is just a binary and it compiles nearly everywhere. +1 over here for agentic fossil. With fossil the "work" is integrated in with the code. Beads separates this out, the beads are instances of work that agents can consume, and they aren't part of the work repo. I could see why you might want t…

Sounds like https://github.com/gastownhall/beads to me. I prefer working solo, single-threaded on components to stay on top of agentic work, so it didn’t end up being a force multiplier for my workflows (and actually kinda got in the way from time to time due to me rebasing too much), but I can see its value when you have many agents working simultaneously.

> have another look at that code So true. beads[0] is such a mess. Keeps breaking often with each release. Can't understand how people can rely on it for their day-to-day work. [0] https://github.com/steveyegge/beads

…in the beads.jsonl? So I wonder does that get line get removed now that it's fixed ... so I check master, but now beads.jsonl is gone? But the readme still references beads.jsonl as source of truth? But there is no beads.jsonl in the dogfooded repo, and there's like ~hundreds of commits in the past few days, so I'm not clear how I'm supposed to understand what's going on with the repo. beads.jsonl is the spoon, but there is no spoon. I'll check back later, or have my beads-superpowered agent check back for me. Agents report that they enjoy this. https://github.com/steveyegge/beads/issues/376#issuecomment-3577259090 https://github.com/steveyegge/beads/commit/c3e4172be7b97effa5010c44b0bfee…