Product Launch
anonymous
57 points
28 comments
Posted6d agoActive4d ago
Beads
github.commvpdeveloper_tooldevelopers
Key Features
Markdown-based task trackinggraph-based task dependenciessingle file bash script
Tech Stack
bash
Key Features
Tech Stack
On the surface though, those are both significantly heavier tools. At minimum, there's a learning or adaption curve. I had built workflows on top of Beads and making a drop-in replacement was easier than reworking all of them.
1. That repo is based on 250+ .go files and stores stuff as git blobs, which is obviously a much more involved, collaboration-focused approach than this tool's 1 .sh file and human-readable markdown files.
2. `tk` seems to be built with agent usage in mind from the jump. I'm sure `git-bug` is perfectly usable, but it's clearly not a focus.
3. The two linux package managers listed for `git-bug` are for (drum-roll, please...) arch and nix. Of course the latter can be setup on every (?) distro, but speaking personally, I find that to be quite the red flag for a devtool! I'm sure it's a bright green ones for fans of those distros/mindsets, of course :)
just to address the package management situation on linux: i currently use nixos, and previously ran arch linux for over a decade. the AUR package is community maintained, as is the nixpkgs package (i maintain it though, so the community doesn't really need to here).
making installation simple on other, more commonly used distributions is a goal, but is less of a priority at the moment than feature work and bug fixes. we're very open to package maintainers on those distributions packaging git-bug, however :)
There aren't a whole lot of tools that have a clean interface for that workflow though.
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.
Not every project needs to have Github as a dependency. Working with Github is added overhead and coordination work that isn't needed for every job.
YYMV, and I get it if you're in a commercial/professional environment, but if you're a solo dev or a small team, then IMO Github doesn't need to be a part of your orchestration (setup project, issue CRUD, pr, etc), just state sync/distribution.
Agents can use local trackers as drop-ins to GH and have similar commands provided to do the same job.
Its fewer moving parts, and more forgiving as you can fix things locally, before pushing out to GH or your Git server of choice.
I agree with OP that beads has great primitives, but I think its become a bit unwieldy in trying to becoming something "everyone" including larger teams can use.
Going to try Ticket out, though personally I prefer JSONL to MD for this kind of tracking, since I find that Claude finds a good concise balance of detail on its own when writing to JSONL vs Markdown files where it tends to be verbose.
Maybe should try to give tickets a go. gh cli does add another HTTP layer and slows things down - feels silly to be paying for Cerebras if one is slowed down by other tooling.
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.
For me, there's a ton of extra control and capability from having things local. Nothing wrong with github, and agents are great with the gh CLI, but it's really not quite the same.
Plus, having it based on directory structure rather than repo means I can locate tickets where the work actually happens. Not everything I work on is on github, and some of the things that are on github are in monorepos where each project really deserves its own set of tickets.
that said for work I use GitHub and have CC make use of the gh CLI, works great. but I have wanted some sqlite/duckdb tracker you could just commit, maybe with back and forth between markdown files. also GH projects are pretty slow/clunky
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 ;)
And I may just go make a README tweak re: unix philosophy... The MVP story floated up from the back of my mind when I went to go build this but you're totally right.
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).
Also, no concept of tags/labels? Are dependencies your primary means of organization?
But yes, dependencies are everything here. I use `tk dep tree` regularly to visualize the graph and click on the things I want details on. Typically I don't have too crazy of a list of open tickets so it's easy enough to find things by running `tk ready` and `tk blocked` and clicking what I'm looking for. For historical things, I just search in the `git log` pager.
If it'd be useful though, I can look at a `tk delete` command that deletes a given ticket and all of its dependencies to clean up a whole tree in one shot. Not sure I'd ever use it myself though.
Tickets by dependency would be nice (although my agent hasn't really used dependencies yet), and ideally something to just quickly wipe out closed tickets with a single command would be nice.
I asked Google/Gemini about a tutorial and it responded with several YouTube videos and also produced this subreddit: https://www.reddit.com/r/AI_Agents/
Found this too: https://nitter.net/bcherny/status/2007179832300581177#m
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.
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.
For more complex environments, use multiple VMs (common to have large VMs running in AWS/GCP for development and only use your laptop or phone as a thin client)
or 8 VMs? won't syncing be super slow there? like i believe it, but it feels like a lot of setup and i don't understand why nobody seems to be talking about it.
Ah, but you can have Claude Code set it up for you!
I personally, can handle only one feature at a time, prompt the AI, refine the changes, re-plan, review changes, rewrite parts when necessary, but my mind is still with one feature.
How do you folks manage multiple parallel feature development at the same time?
Long before AI I routinely had 5 parallel development environments I would flip between. (I do distributed systems stuff, think HPC-adjacent clusters, when you're too big for Kubernetes and too small for supercomputing). One would be running long-running tests for my current changes, one being reset to a clean state, and 3 more on standby so I had 100% "duty cycle" (the reset took a while). You got used to multitasking.
In case of AI, it just delivers things in 2-3 minutes, this time is not enough (or worth) to switch the context (for me personally)
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
I may actually make a slimmer one for that use case though. There are a number of commands here that are really only useful at the orchestration layer and would be mostly noise in a pure Skill context.
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.
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.
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.
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.
Not affiliated with Hacker News or Y Combinator. We simply enrich the public API with analytics.