Bots that finish a half-done migration #95

A migration starts with something that does most of the work. A codemod rewrites every call it can prove is safe, a dependency bump lands with release notes listing what broke, or an upgrade guide names the APIs that moved. Then it stalls on what's left: the calls the codemod couldn't prove, the call sites the notes describe but nobody has rewritten, and the API with no one-to-one replacement on the other side. The old way and the new way live side by side in the codebase for months.

Some of what's left has a clear answer once someone reads the surrounding code and the notes: a renamed parameter, a method that moved namespaces, a wrapper that's a thin pass-through. The rest is a real decision, like what should replace a call the new version simply doesn't have. A gitbot can migrate the first kind itself and bring the second kind to a person, with the call sites it found and the notes that bear on each one.

We'd take bots across kinds of migration (codemod leftovers, dependency and framework upgrades, SDK or vendor swaps, deprecated APIs, language version bumps) and across ecosystems (npm, pip, Go modules, Terraform providers).

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.