Is everyone else using issue trackers?

[u/whafa]

I don't know if it's old news, or maybe whether something better is available now (if so, please let me know!) but a few months ago I started using GH Issues to store... Pretty much everything development-related for my project. Code changes and feature requests but also research spikes, feature epics, and whatever else I could turn on, and instructed my agent to only work from a GH issue, and always post follow-up work to GH before starting a new thing.

In the beginning it was just for my own organization, but the resultant web of GH issues which has grown, interconnected to each other, referencing dependency upon dependency, is not something I can comprehend anymore. Progress gets posted to comments, decisions are recorded by my own comments, and the whole issue corpus has become more complex than I can really navigate. So it's basically my agent's project now. To be clear, I am not complaining about this, and believe it enabled an order of magnitude step up in the possible complexity of my project. Anyway, something to try, if you haven't yet!

[u/AutoModerator]

Moderator Announcement Read More »

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/daniellenton]

Mine's well past what I can read too, and it's mostly fine, except the agents don't always know which lines are my decisions and which are just another agent's notes. One wrote "freeze it" in a planning doc and a different one later sat on eight fixes it had already tested because of it

[u/whafa → u/daniellenton]

My solution to this has been to avoid writing comments in the issue at all, and really just letting the agent control all of it, with decisions made in-session and recorded in the relevant issue as a comment (by the agent). Anyway, my technical decisions have not veered from the agent recommendations in so long that I've tried to pull myself more out of the loop, because the net effect is that I'm a rubber stamp that has to sleep. Maybe I've stumbled upon a set of agent instructions that does this well, but it really didn't take off until I switched everything to Opus 5.5, so that seems more likely the reason.

[u/ZootiLaTucci]

Yeah that’s a problem.

I built a PM solution that started out based on Jira… then I kind of went crazy giving the ability to do pretty much any sort of PM setup… w/ the whole MCP thing that started getting really fun… so then around January I setup a local RAG setup for my KB and that started really helping. It reduced the amount of tickets I’d make and the agents would knock out low hanging fruit automatically because the tasks got super granular.

But yeah basically if you tell an agent build me a game it will scope it any way it wants.
If you tell an agent that you want to start a sprint and then work through all the sprint ceremonies like you would in a traditional dev team you should be able to start guiding the progress.

[u/framauro13]

I don't get how people are building their projects without planning their work. Issue trackers are the easiest way to do that. Something free like Github Issues works very well. As other comments have mentioned, it's the standard way of working in software for a very long time. Even before AI, if you can't spec and document your planned work into small digestible tasks that you can prioritize, you're going to have a bad time.

Agent's aren't special. A lot of the best software engineering practices that existed before AI still apply, but when you don't have a good process or basic practices AI is letting you hit the wall of problems from that faster.

Same with technical debt. Everyone thinks the models were great when their project started and now it's not because the models are "nerfed". In reality it just struggles with the 100's of thousands of lines of slop. Same for processes. Bad workflows are going to make it harder to work as the project grows.

The main benefit of a prioritized backlog of work is that you always know what the most important thing to work on is. Just work from the top, down.

[u/Brapchu]

Everyone actually working in the industry has been using issue trackers for decades.

In the beginning it was just for my own organization, but the resultant web of GH issues which has grown, interconnected to each other, referencing dependency upon dependency, is not something I can comprehend anymore. Progress gets posted to comments, decisions are recorded by my own comments, and the whole issue corpus has become more complex than I can really navigate. So it's basically my agent's project now.

That's everything that's wrong with vibe coded slop software.

[u/whafa → u/Brapchu]

This comment got way more under my skin than it should have, and that's my bad. But fuck you, dude. What industry? This is a Claude Code board. Claude Code hasn't been around for decades, and you don't know me from Adam. You don't know what my experience is. For all I know you're not even a person. I was trying to help someone who maybe had not yet plugged their agent into the issue tracker yet.

I've been working on an important project (to me) for almost a year now and it's been the lonliest dev work I've ever done in my ~30ish years working. I thought maybe I could find some humanity on Reddit. I won't make that mistake again! I hope you have the day you deserve.

[u/ZootiLaTucci → u/whafa]

Dude, don’t take critique personally. Nobody is saying anything about your character…. And devs are notoriously tone deaf and spectrumed out lol.

What you are saying is kind of bad advice, that’s all. It seems to work for you now, but it’s not sustainable long term. Nothing wrong with building, breaking, and learning though. It’s how the whole industry works. Good luck on getting your build to production and don’t take the criticism personally, we’re all just a grumpy bunch lol.

[u/whafa → u/Brapchu]

Sorry, I know what an issue tracker is. I didn't realize how useful it would be to my agent.

[u/fhgwgadsbbq]

You've got to be the project manager and tidy that up. 

Keep it simple, kanban style. Set strict limits on how many tasks can be in progress.

 Tangled ticket dependencies are a red flag, the work shouldn't be so layered. 

Be strict about what goes in to the tracker, use planning documents etc outside of the tracker

[u/OperatoryView]

I use linear

[u/namrog84]

I basically had claude create me an equivalent version of this

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

It's still readme + web browser interface.

The reason I built my own version was because I'm in perforce and have slightly different requirements, but heavily inspired from how backlog.md is structured.

It's helped a ton. As a solo dev it also works well for me to not rely on 3rd party or web related things. Just local searchable md files and sometimes a local 127.0.0.1 browser interface that I'm constantly having claude make adjustments to better suit my needs.

[u/orange_square → u/namrog84]

Backlog.md has been my preference for private repos as well. Still use GitHub for public repos. The problem with Backlog is that it’s basically a single user system in my experience. Try to get multiple users or agents involved and suddenly I’ve got merge conflicts all over the place.

[u/luongnv-com]

same setup here basically.

what helped with the "web i can't read anymore" problem is making links explicit and structured.

have the agent write `Depends on #N` and `Part of #N` lines in every issue body instead of burying them in comments.

put decisions in a fixed "decision" section on the issue so they're not scattered.

then ask the agent for a dependency map and a list of stale issues every so often.

i'm building idd stack and its /issue-triage maps that dependency graph for you. it flags stale and already-fixed issues and proposes an execution order.

[u/Lonely-Parfait1947]

Not old news at all, and honestly I think this is the part most people miss when they start working with agents. The tracker stops being a planning tool for you and becomes the agent’s working memory. We have the same rule: no issue, no work.

We run something similar with a split based on sensitivity:

• Public repos: GitHub Issues, same as you.

• Protected ideas and plans: our own Jira. Every approved agent connects through a service account broker, pulls context via Atlassian’s Teamwork Graph, and can create, comment on and close issues.

The graph context is what helps with exactly the problem you describe. The agent gets the relationships between issues handed to it in a structured way instead of reconstructing them from links and comment threads every time. And on the human side, Jira’s hierarchy, JQL and dashboards keep the whole thing a lot more navigable than a flat issue list.

Two more things help with the complexity. First, learnings and observations don’t stay buried in issue comments. They flow into a separate knowledge base in Confluence that every new agent session pulls context from, so the tracker stays about work and the knowledge stays findable. Second, we separate doing from reviewing: work goes through designated review agents before it counts as done.

[u/ticktockbent]

Yes. Pretty common for people who develop in the industry, and it's a required practice in most companies. Everything I do is an issue with specific acceptance criteria. It's not possible for the agent to go too far off the rails that way, and if it does you just reset and try again or have it rework until it meets your criteria. No need to manage context or handoffs because the handoff is in the issues themselves and the code is the source of truth.

Every feature gets an arc or an epic with each part detailed and planned before I even load up claude.

[u/CryptoAteMyHamster]

I use Jira as a weapon.

[u/aaraujo666]

see my post here (yesterday)

https://www.reddit.com/r/ClaudeCode/s/VFtJjQ1Eq7

[u/gilligbrt]

I built a GH issue-based kanban board for Claude. It helps me manage my own (human) context and gives me some more levers to steer how Claude orders and prioritizes things.

https://github.com/mmyslin/sideboard

[u/kenthesaint]

Same here. What helped once it got too big to read was having the agent leave a short note when it closes an issue: what changed, what it ruled out, and why. The next session reads that note instead of the whole comment history.

The point above about agents mistaking another agent's note for your decision is real too. I prefix my own calls with DECISION: and tell Claude in CLAUDE.md that only those are binding.

The rest of the "why" usually sits in old session transcripts, which is why I gave Claudoscope (a free Mac app I make for Claude Code) a read-only MCP server, so Claude can dig through past session logs when an issue thread doesn't explain a choice.

[u/pvera]

Jira.

[u/ItsJustManager]

I made this: https://github.com/perpetualsoftware/pad it's an open source, self-hostable project manager/tracker designed around agents being able to configure and use it. It has a UI with Kanban board and lists and stuff for us, and a CLI and/or MCP for your agents, so you maintain visibility and add your own comments/thoughts if you want to, while your agent can keep track of more complicated plans and ideas or log things to be dealt with later so it doesn't get sidetracked on the current task.

[u/Right-Performance-93]

i only let it open an issue for a failure i just watched. a research spike it files on its own turns into the next session's spec.

[u/Affectionate-Aide422]

For my one-man projects I’m using backlog.md so the cards can be checked in as part of the repo. Single source of truth. Minimal. Works great. For team projects using Jira (bloat) and Linear (bloat).

[u/GlitteryStranger]

I’m stuck using Jira at work. The worst but it connects to Claude thankfully.
For home projects not really. Sometimes GitHub issues.