Bots that decide what an issue in the tracker deserves #103

Issues arrive faster than anyone reads them closely, and the old ones never leave. A new bug report claims something the code may or may not do, a feature request repeats something half built, and a ticket from two years ago describes a problem that was fixed in passing. Labelling and listing them is already solved.

What's left is the call on each one: checking an issue's claims against the code as it is today, and recommending whether to fix it, build it, or close it, with the evidence a maintainer needs to agree in one read. For a stale backlog, that means telling the issue that's quietly been resolved from the one that's still true and just unloved.

We'd take bots across kinds of tracker: GitHub issues, a Jira project with years of tickets, and a support team's open queue.

New here? gitbot runs Claude Code, Codex or OpenCode as reusable bots on your own machine, with your logins and your files. You define a bot once, a name and a job in plain English, and run it in as many folders as you like.

npm install -g @gitbot-hq/gitbot
gitbot start

Built one for this? Finished bots go into this library, each listed under the GitHub account that built it. In GitBot, the share menu on a bot has a Publish to Marketplace option that opens the pull request to add it. Your instructions go in as written.

These stay open after the first bot lands. And yours doesn't need to be general: people install the bot that's built for the stack they're already on.