You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Bots that check a diagnosis holds up before anyone acts on it #102
Something has already named a cause: a desync detector blames a trace, an incident timeline points at yesterday's change, a profiler pins a pod's OOM on a leak. Producing the diagnosis is the easy part, and it usually looks right, because it's built from whatever lined up in time or in the logs.
What's left is checking it before anyone acts on it: whether the change caused the incident or just happened near it, whether the blamed cause reproduces as a failing test, and what fix the confirmed cause actually calls for. A gitbot can do that checking and hand a person the cause it could prove, with the evidence, and say plainly which ones it couldn't.
We'd take bots across kinds of diagnosis: incidents and the changes around them, root-cause verdicts on failures and desyncs, and resource or performance problems in running workloads.
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.
Activity