5 ms·

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

84 points by wild_egg 9mo ago

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.

deleted 9mo ago
[deleted]
nmfisher 9mo ago
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.
khimaros 9mo ago
why should people use this as opposed to https://github.com/git-bug/git-bug https://github.com/git-bug/git-bug?
- khimaros 9mo ago
  or if that's not similar enough, how about https://github.com/dspinellis/git-issue https://github.com/dspinellis/git-issue?
  - wild_egg 9mo ago
    I'm not familiar with enough to say concretely. What's the dependency management experience like with those? That's really the core of my needs. 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.
- bbor 9mo ago
  Just glancing at it: 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 :)
  - sudoforge 9mo ago
    hey, git-bug maintainer here! 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 :)
arjie 9mo ago
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.
- wild_egg 9mo ago
  Is there a way to do dependency tracking with `git notes`? That's really the core thing for me. I like to do a ton of up-front planning work, split it all out into a graph of tickets and then let agents chew threw them until done. There aren't a whole lot of tools that have a clean interface for that workflow though.
  - handfuloflight 9mo ago
    If you could describe it, what would the ideal interface for that be?
  - arjie 9mo ago
    The notes can have references. So I just have it name the other notes that are relevant. I don't do the toposort you're talking about but I do the referencing.
jannniii 9mo ago
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.
- dkdcio 9mo ago
  vendor lockin + slow network calls (+ GitHub is down sometimes). if you want to search over hundreds of issues, `gh search` isn’t bad but you can do a lot better with a filesystem or embedded database 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
- shankspeaks 9mo ago
  IMO Beads, Ticket, etc. give you optionality. Not every project needs to have Github as a dependency. Its added overhead and coordination work that isn't needed for every job. YMMV, 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.
  - jannniii 9mo ago
    Yes, I get it. Personally dancing between commercial work (GH) and personal (no need for GH). Because of orchestration setup works for former end up using also for latter. 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.
bbor 9mo ago
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 ;)
- wild_egg 9mo ago
  Thanks! I agree completely. Dependency tracking is such a vital part of organizing work and it's hard to find good tooling for that. Beads started out as one and I wanted to maintain the simplicity it used to offer. 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.
- rollcat 9mo ago
  I feel like using Bash is a double-edged sword. Yes, it's available on every modern unix-like (notably absent from the base system in the *BSDs), but the language (being an sh descendant) is honestly horrible for anything more complex than 200-300 lines of plugging one command into another. Ticket isn't even pure Bash; it embeds several inline, 100+-line AWK scripts, and a giant jq query (an external tool!). All of which is horrible for syntax highlighting, mind you. 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).
code_martial 9mo ago
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.
cloudking 9mo ago
Nice solution, I had some success with https://www.task-master.dev/ https://www.task-master.dev/ it's a bit more complex though
lukefreiler 9mo ago
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?
- wild_egg 9mo ago
  Ah I don't delete these or really look at the `.tickets/` directory. I have about 1900 tickets in one project and navigate them through VS Code. Ctrl+t does fuzzy finding across all markdown headers and I Crtl+Click in the terminal quite a lot to jump to ticket files. 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.
  - lukefreiler 9mo ago
    I'd find it handy. I think there's some risk in agents tripping over stale tickets and consuming tokens - I see it with .md all the time. 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.
    - lemming 9mo ago
      Or at least move them to a .tickets-done directory, so if the agent is searching under .tickets it won't see them, but you retain some history.
neumann 9mo ago
Is there a mini tutorial demonstrating best practices for people keen to try but who haven't used agents like this?
- hasbot 9mo ago
  Good question though I expect it'll get buried amongst all the other comments. Maybe create an "Ask HN" post. 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/ https://www.reddit.com/r/AI_Agents/ Found this too: https://nitter.net/bcherny/status/2007179832300581177#m https://nitter.net/bcherny/status/2007179832300581177#m
  - neumann 9mo ago
    Thank you. It is always intimidating to see how people are using 5-10 agents for coding, but haven't seen practical examples of the process and how people do this specifically.
- wild_egg 9mo ago
  I've actually built up a set of Claude Skills for creating and using tickets. Currently overhauling them based on what I've found to be most effective. Will probably publish those in a week or two when I've nailed down what I want there. 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.
bredren 9mo ago
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 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.
lemming 9mo ago
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.
- wild_egg 9mo ago
  Great call out. The agents will set those on `create` calls but don't typically reference them afterwards. 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.
dev_l1x_be 9mo ago
How is merge handled?
skrebbel 9mo ago
Vaguely related question, for people who run multiple agents in parallel: how do you do that? do they all work on the same files at the same time? won't that create a terrible mess? or do you like check out the codebase 8 times into separate directories and do a complicated PR flow type thing?
- trivialities777 9mo ago
  you can use https://git-scm.com/docs/git-worktree https://git-scm.com/docs/git-worktree to have many "views" of a single git repo. 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)
  - skrebbel 9mo ago
    I don't follow, so these people using 8 claude codes in parallel, they have 8 git worktrees? and 8 devservers listening on 8 ports? 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.
    - trivialities777 9mo ago
      > but it feels like a lot of setup Ah, but you can have Claude Code set it up for you!
- throwaw12 9mo ago
  I am also curious about this, how people wrap their head around multiple changes in multiple features at the same time? 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?
  - trivialities777 9mo ago
azeirah 9mo ago
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 :)
czottmann 9mo ago
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 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.
xdanger 9mo ago
I've found Backlog.md quite nice https://github.com/MrLesk/Backlog.md https://github.com/MrLesk/Backlog.md has a nice tui/webui for me, and mcp for the agent.
Kindercrusher 9mo ago
[dead]
piotraleksander 9mo ago
Wouldn’t it make perfect sense to wrap this in a Claude Skill instead of distributing as a separate package?
- wild_egg 9mo ago
  It really would. That's on my TODO list for next weekend. 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.
stefanoco 9mo ago
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
NamlchakKhandro 9mo ago
why do all these projects assume i want to store this stuff in my current repo?
- nbbaier 9mo ago
  Curious, where would you want to store it? The current repo doesn't seem like thst bad of an option
Zaloog 9mo ago
I just added a cli Interface to my existing tool kanban-tui. 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.

84 points by wild_egg 9mo ago

deleted 9mo ago

[deleted]

nmfisher 9mo ago

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.

khimaros 9mo ago

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

khimaros 9mo ago
or if that's not similar enough, how about https://github.com/dspinellis/git-issue https://github.com/dspinellis/git-issue?
- wild_egg 9mo ago
  I'm not familiar with enough to say concretely. What's the dependency management experience like with those? That's really the core of my needs. 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.
bbor 9mo ago
Just glancing at it: 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 :)
- sudoforge 9mo ago
  hey, git-bug maintainer here! 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 :)

arjie 9mo ago

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.

wild_egg 9mo ago
Is there a way to do dependency tracking with `git notes`? That's really the core thing for me. I like to do a ton of up-front planning work, split it all out into a graph of tickets and then let agents chew threw them until done. There aren't a whole lot of tools that have a clean interface for that workflow though.
- handfuloflight 9mo ago
  If you could describe it, what would the ideal interface for that be?
- arjie 9mo ago
  The notes can have references. So I just have it name the other notes that are relevant. I don't do the toposort you're talking about but I do the referencing.

jannniii 9mo ago

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.

dkdcio 9mo ago
vendor lockin + slow network calls (+ GitHub is down sometimes). if you want to search over hundreds of issues, `gh search` isn’t bad but you can do a lot better with a filesystem or embedded database 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
shankspeaks 9mo ago
IMO Beads, Ticket, etc. give you optionality. Not every project needs to have Github as a dependency. Its added overhead and coordination work that isn't needed for every job. YMMV, 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.
- jannniii 9mo ago
  Yes, I get it. Personally dancing between commercial work (GH) and personal (no need for GH). Because of orchestration setup works for former end up using also for latter. 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.

bbor 9mo ago

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

wild_egg 9mo ago
Thanks! I agree completely. Dependency tracking is such a vital part of organizing work and it's hard to find good tooling for that. Beads started out as one and I wanted to maintain the simplicity it used to offer. 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.
rollcat 9mo ago
I feel like using Bash is a double-edged sword. Yes, it's available on every modern unix-like (notably absent from the base system in the *BSDs), but the language (being an sh descendant) is honestly horrible for anything more complex than 200-300 lines of plugging one command into another. Ticket isn't even pure Bash; it embeds several inline, 100+-line AWK scripts, and a giant jq query (an external tool!). All of which is horrible for syntax highlighting, mind you. 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).

code_martial 9mo ago

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.

cloudking 9mo ago

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

lukefreiler 9mo ago

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?

wild_egg 9mo ago
Ah I don't delete these or really look at the `.tickets/` directory. I have about 1900 tickets in one project and navigate them through VS Code. Ctrl+t does fuzzy finding across all markdown headers and I Crtl+Click in the terminal quite a lot to jump to ticket files. 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.
- lukefreiler 9mo ago
  I'd find it handy. I think there's some risk in agents tripping over stale tickets and consuming tokens - I see it with .md all the time. 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.
  - lemming 9mo ago
    Or at least move them to a .tickets-done directory, so if the agent is searching under .tickets it won't see them, but you retain some history.

neumann 9mo ago

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

hasbot 9mo ago
Good question though I expect it'll get buried amongst all the other comments. Maybe create an "Ask HN" post. 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/ https://www.reddit.com/r/AI_Agents/ Found this too: https://nitter.net/bcherny/status/2007179832300581177#m https://nitter.net/bcherny/status/2007179832300581177#m
- neumann 9mo ago
  Thank you. It is always intimidating to see how people are using 5-10 agents for coding, but haven't seen practical examples of the process and how people do this specifically.
wild_egg 9mo ago
I've actually built up a set of Claude Skills for creating and using tickets. Currently overhauling them based on what I've found to be most effective. Will probably publish those in a week or two when I've nailed down what I want there. 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.

bredren 9mo ago

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

lemming 9mo ago

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.

wild_egg 9mo ago
Great call out. The agents will set those on `create` calls but don't typically reference them afterwards. 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.

dev_l1x_be 9mo ago

How is merge handled?

skrebbel 9mo ago

Vaguely related question, for people who run multiple agents in parallel: how do you do that? do they all work on the same files at the same time? won't that create a terrible mess? or do you like check out the codebase 8 times into separate directories and do a complicated PR flow type thing?

trivialities777 9mo ago
you can use https://git-scm.com/docs/git-worktree https://git-scm.com/docs/git-worktree to have many "views" of a single git repo. 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)
- skrebbel 9mo ago
  I don't follow, so these people using 8 claude codes in parallel, they have 8 git worktrees? and 8 devservers listening on 8 ports? 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.
  - trivialities777 9mo ago
    > but it feels like a lot of setup Ah, but you can have Claude Code set it up for you!
throwaw12 9mo ago
I am also curious about this, how people wrap their head around multiple changes in multiple features at the same time? 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?
- trivialities777 9mo ago

azeirah 9mo ago

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

czottmann 9mo ago

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

xdanger 9mo ago

I've found Backlog.md quite nice https://github.com/MrLesk/Backlog.md https://github.com/MrLesk/Backlog.md has a nice tui/webui for me, and mcp for the agent.

Kindercrusher 9mo ago

[dead]

piotraleksander 9mo ago

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

wild_egg 9mo ago
It really would. That's on my TODO list for next weekend. 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.

stefanoco 9mo ago

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

NamlchakKhandro 9mo ago

why do all these projects assume i want to store this stuff in my current repo?

nbbaier 9mo ago
Curious, where would you want to store it? The current repo doesn't seem like thst bad of an option

Zaloog 9mo ago

I just added a cli Interface to my existing tool kanban-tui. 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.