Bots that explain why a CI run failed #93

A CI run fails and the log says which step broke, but not why. A build broke because a dependency resolve picked up a new transitive version overnight, a runner drifted from the image the job expects, or a credential expired between runs. A gate failed because coverage missed its threshold or a size budget was exceeded, and the summary names the metric but not the branch or the change behind it.

A gitbot can read the whole run, the console log, the test results and the artifacts behind a gate, and work backward to the cause. Some causes have one right answer sitting in the log once you know where to look: the uncovered branch, the dependency that moved, the diff that grew the bundle. Others, especially intermittent infra or environment drift, mean the bot should stop and bring a person a short list of plausible causes with the evidence for each, rather than keep guessing.

We'd take bots across CI systems (Jenkins, GitHub Actions, CircleCI, GitLab CI) and kinds of gate (tests, coverage, static analysis severity, performance or size budgets).

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.