Bots that decide whether a suggested dependency replacement is safe to take #87

A tool flags a dependency as abandoned, vulnerable, or deprecated, and names a replacement: a maintained fork, a successor package, sometimes a different vendor entirely. Naming the replacement is the easy part. Nobody has checked whether it actually drops in: same calls, a license that still fits, a project that isn't itself six months from the same flag.

What a gitbot adds splits in two. Where the two packages line up one-to-one, that's checkable, and the bot can confirm it and open the migration pull request itself. Where they don't, a renamed call, a config shape that changed, a license that doesn't match, that's a real decision, and the bot should bring it to a person with what it found rather than force the swap through.

We'd take one per ecosystem that flags these: RubyGems, npm, PyPI, and crates all surface abandoned or deprecated packages with a suggested successor.

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.