Show HN: I replaced Beads with a faster, simpler Markdown-based task tracker (github.com)
I've been running long duration coding agents with Claude Code for about 6 months now. Steve Yegge released Beads back in October and I found that giving Claude tools for proper task tracking was a massive unlock. But Beads grew massively in a short time and every release made it slower and more frustrating to use. I started battling it several times a week as its background daemon took to syncing the wrong things at the wrong times.
Over the holidays I finally ripped it out and wrote ticket as a replacement. It keeps the core concept I actually cared about (graph-based task dependencies) but drops everything else.
ticket a single file bash script built on coreutils managing flat files. You don't need to index everything with SQLite when you have awk. It's just a small plumbing utility that gets out of your way so you can get to work.
Would love feedback on gaps. I built this for my own agent workflows so there are probably use cases I haven't thought about.
28 comments
[ 5.6 ms ] story [ 54.1 ms ] threadWhat I do not understand about beads or alternatives such as this is: why not just use github issues? Or is it just the aversion of being tied to github?
My agent team does, easy to tell them so and give them access to suitable gh commands.
Forgejo is a single go binary and very fast.
You can script it using an API, you have full access to the database which can be sqlite3 or postgres.
Then you get all the benefits of an integrated issue tracker which has a great GUI for humans to review.
I really don't understand the raison-de-etre for beads other than yak shaving, and would really like to.
More relevantly: I've spent way too long rolling my own issue tracking systems (plural!) over the years, and it's good to see someone else share my intuition that dependencies and tagging are by far the most important part of solo-ish issue trackers. You'd be shocked how many massive tech companies publish issue trackers where dependencies are an afterthought (or worse: a paid upgrade).
My only tiny, soft suggestion would be mention "Unix Philosophy" rather than just the MVP link, tho it is indeed cute. As I alluded to above, the former has a dedicated cult behind it already ;)
These days Python is almost as universally available, and I've seen few systems ship without Perl. Both provide excellent backward compatibility; I have many scripts that still run unchanged on Python 3.6 (2016).
Long winded way to say that it’s now easier to just create something to fit your needs… like 3D printing components.
Claude Code already has a built-in task tracker for short/mid term tracking.
Also, no concept of tags/labels? Are dependencies your primary means of organization?
I haven't seen any great content around this though. I've gone through a lot of trial and error with different approaches over the last few months.
Biggest thing I can say: plan up front. I frontload basically all of my involvement and have Claude do a ton of research to make a very detailed plan document and then the plan gets decomposed into a graph of tickets. I have some other tooling that orchestrates delegating the tickets to focused Claude Code sessions and they can work through them mostly autonomously for many hours until the work is done.
I wasn't able to find something AI-native that supported subissues, and worked across projects. I require git worktrees on my programming work now, and I want it to be able to handle integration with systems like Linear or even GH issues (which was my preferred ticketing system before CLIs emerged)
The idea is in part, ~I have 15 minutes right now, what is the most important thing to put attention to? Be routed to the project and go immediately to work with a CLI.
I'm using Claude Code and codex for programming and administrative chores now. For example, managing the process of finding and selecting an arborist.
My main personal project, focuses on making Claude Code and Codex conversations useful (https://Contextify.sh). I use uses pure markdown (TODOS.md) for issue management and it is at its limit.
I'm less concerned about the DB's storage location. I don't think it needs to be stored with each project, but each project does need to be able to access it.
I suspect that I'll ultimately want to host it.
Since these seem more lightweight/ephemeral, it seems like it would be useful to search upwards for the nearest enclosing .tickets directory, so that subsystems could have separate issues.
I have a fairly robust orchestration layer built on top of this tool that relies heavily on those fields though. But without that, they are a bit noisy.
Mixed feelings on upward search. One of my pain points with beads was that agents would sometimes create a bead outside of the correct directory and get dumped into a global `~/.beads/default.db` and make a mess. They've done that a couple times with ticket but run `tk ready` afterwards, see the new ticket is the only one, realize their mistake, and then relocate the ticket into the correct location. Still thinking on that one.
0 https://www.vibekanban.com/
Some people have multiple agents working in the same directory, and allow the agents to tell each other what they're doing and which files they're editing: https://github.com/Dicklesworthstone/mcp_agent_mail
Thanks a lot for this! I was interested in beads but found the author's approach to software development quite erratic and honestly a bit unprofessional. Yes, LLMs are great, but no they shouldn't be the lead developer.
Beads is an incredibly difficult-to-follow mess for something that is at its core a pretty simple idea. You distilled it to its core, I will absolutely be checking this out :)
https://github.com/hmans/beans
> Beans is an issue tracker for you, your team, and your coding agents. Instead of tracking tasks in a separate application, Beans stores them right alongside your code. You can use the beans CLI to interact with your tasks, but more importantly, so can your favorite coding agent! > > This gives your robot friends a juicy upgrade: now they get a complete view of your project, make suggestions for what to work on next, track their progress, create bug issues for problems they find, and more.
Much, MUCH less invasive than beads (basically just a CLI tool and a `.beans.yml` & `.beans/` in your project, and a joy to work with. CLI, TUI, labels, status, types (epic, feature, task etc.), GraphQL query interface (agents love that).
It's good.
https://github.com/MrLesk/Backlog.md
has a nice tui/webui for me, and mcp for the agent.
Now I can let the agent create tasks and work on them via cli and I can monitor or add new tasks on the fly on the TauI without needing to interrupt the agent. Using sqlite backend, if you use it as a local skill, it doesnt create files in your repo
„uvx kanban-tui skill init“ to get the skill and get started.