or if that's not similar enough, how about https://github.com/dspinellis/git-issue?

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

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.

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

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.

It's a great question. I'm sure the answer varies a lot by who you ask.

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.

This is my question, and why not go a step further and just self host foregjo?

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.

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.

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

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.

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/

Found this too: https://nitter.net/bcherny/status/2007179832300581177#m

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.

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.

you can use 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)

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?

Git worktrees for parallel repo clones on different branches, a worktree setup script that runs when a worktree is created (npm install etc) and vibe-kanban [0] to visually create, monitor and approve parallel work

0 https://www.vibekanban.com/

Some people use git worktrees so each agent is working in a separate directory.

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

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.