HN Reader

Show HN: I replaced Beads with a faster, simpler Markdown-based task tracker

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.

There's also Beans, doing MD-based ticketing in your project. It's really good. (Disclaimer: I've contributed a few of the agent rules.)

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.

3 days agoby czottmann

I just asked Claude to create a memory system for itself for one of my projects. It created a file based utility written in Rust on its own. I offered it to use beads but it declined as beads is a task tracker and what we needed was a spec tracker.

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.

3 days agoby code_martial

I would love to have a nix flake to install it easily with nix! Given it's built in bash that should be basically no issue whatsoever.

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 :)

3 days agoby azeirah

I have been looking at this problem space, including beads recently.

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.

3 days agoby bredren

Looks great, well done.

What 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.

3 days agoby jannniii

Digging the idea and incredibly simple implementation - but do you have a model in mind for clean-up? I've been working with it for an hour and have ~30+ tickets across a series of tasks, which are all just named by ID so no obvious way to purge (I could be missing something obvious).

Also, no concept of tags/labels? Are dependencies your primary means of organization?

3 days agoby lukefreiler

I started playing around with beads, but when I got to the phrase "landing the plane" I started looking for simpler alternatives. So far, this looks much closer to what I want (flat files, human readable, basic syntax). Looking forward to putting it through its paces over the next few weeks.

4 days agoby nmfisher

3 days agoby skrebbel

For solo projects I just use `git notes`. It's all in the same place, you can push them, and Claude Code just needs to be told that they exist. It knows how to use them and it's totally fine. They don't have merge logic, though, so don't use them in collaborative projects.

3 days agoby arjie

Oh my lord it's written in bash. That's incredible. Well done! It's good to feel like the new kid sometimes as I approach 30 and ossify technically -- I'm sure this will develop a healthy fanbase of senior engineers, if the one's I've known are anything to go off of.

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 ;)

3 days agoby bbor

I'm curious, and in the spirit of a true MVP - does this need type, assignee, links or the parent relationship? Do you see the agent using them in practice? It seems like a minimal implementation could do without all of those, and I wonder if they're useful to the agent, or are just documentation for humans.

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.

3 days agoby lemming

Anyone thinking of adding a feature or separate tool for exporting existing gitlab/github issues to this Ticket or Beads? Looks like in the Agentic Era having issues/tickets managed using this kind of tools and kept in folders side by side with code and documents is much more desirable than separating them to web based git servers

3 days agoby stefanoco

Wouldn’t it make perfect sense to wrap this in a Claude Skill instead of distributing as a separate package?

3 days agoby piotraleksander

I've found Backlog.md quite nice

https://github.com/MrLesk/Backlog.md

has a nice tui/webui for me, and mcp for the agent.

3 days agoby xdanger

Nice solution, I had some success with https://www.task-master.dev/ it's a bit more complex though

3 days agoby cloudking

why should people use this as opposed to https://github.com/git-bug/git-bug?

3 days agoby khimaros

Is there a mini tutorial demonstrating best practices for people keen to try but who haven't used agents like this?

3 days agoby neumann

How is merge handled?

3 days agoby dev_l1x_be