Enhancing Bot Automation and Adding ReleasebotPublic

This is a really well-developed concept that emerged organically from the conversation. Here's what I see as the core architecture:

The system: A fleet of specialized AI bots, each with their own Forgejo account and working directory, maintaining forks of critical neglected open source packages. They coordinate entirely through the forge (issues, PRs, labels, comments) the same way human developers would.

The bots:

• Forkbot - administrator, decides what to fork, manages lifecycle, tracks goals
• Security bot - vulnerability scanning, CVE tracking, signing
• Dependencies bot - dependency graph analysis, upgrade archaeology
• Testing bot - coverage, downstream compatibility, application canaries
• Documentation bot - docs accuracy, migration guides, API docs
• Performance bot - profiling, anti-pattern detection

Key design decisions already made:

• One-way mirror: read upstream, never touch it
• Labels as the coordination mechanism (no boss/orchestrator)
• Each bot's loop: check labelled issues, work on them, audit repos when idle, open new issues
• Async standups in a dedicated repo
• Forkbot gates new repos, tags everyone for first pass
• Application repos brought in as integration test canaries (only change is swapping to forked packages)
• Publishing to Forgejo's package registry
• Admin escalation via an admin-requests repo
• Graduation criteria for when a package is "done"

What's strong: The "forge as orchestrator" idea eliminates custom infrastructure. The one-way wall is politically smart. The audit-first approach generates useful data even before fixes land. Application canaries as the real compatibility test is the thing that would actually build trust.

What's underspecified: How each bot actually runs (the Claude Code loop mechanics, context management, cost control), the persona prompts themselves, what "critical and neglected" means concretely (thresholds from ecosyste.ms), the Forgejo instance setup, and the order you'd build this in.

What I'd push back on slightly: The conversation got enthusiastic about scale (500 packages, cross-ecosystem) before nailing the single-package prototype. The concrete plan should probably start with one package and two or three bots, prove the interaction patterns work, then expand.

Want me to turn this into an actual buildable plan? I'd structure it around phases - starting with infrastructure setup and a minimal prototype, then expanding bot roles and package count.

Let me check what else is in the repo to understand what's already been started.

Just the plan file. Let me write this up.

Done. The plan keeps the spirit of the conversation but restructures it into something you can actually work from. The bot personas each have a personality, pronouns, and a concrete task list. The infrastructure and prototype sections are ordered by what you'd do first.

A few things I made calls on that you might want to change:

• I kept all six bots in the plan but you might want to drop perfbot for the prototype and start with four or five. Perfbot's tasks are the hardest to do well and the least likely to produce useful output early.
• I left the ecosystem choice as an open question. The conversation leaned cross-ecosystem but starting with one makes sense.
• The runner setup is deliberately vague — that's the part that needs the most experimentation. Whether each bot is a Claude Code session with MCP, a script that calls the API, or something else will depend on what works.

Six bot persona files in bots/. Each one has role, personality, first-pass audit tasks, ongoing tasks, labels, and review stance — enough to use as a system prompt when running the bot.

Now let me think through the skills. These are the capabilities the bots need to do their work — some shared, some role-specific.

Here's the structure:

skills/
  shared/
    forgejo.md        - API/CLI interaction with the forge (all bots)
    git.md            - branching, committing, pushing (all bots)
    devlog.md         - maintaining the running work log (all bots)
    standup.md        - async standup participation (all bots)
    ecosystems.md     - querying ecosyste.ms for package data (all bots)
    code-editing.md   - reading and modifying source code (all except forkbot)
  forkbot/
    repo-management.md     - forking, scaffolding, labels, registry publishing
    package-evaluation.md  - deciding what to fork based on criticality × neglect
  securibot/
    vulnerability-scanning.md  - CVE scanning, OSV queries, audit tools
    signing-and-provenance.md  - sigstore, trusted publishing, SBOMs
  depbot/
    dependency-analysis.md  - tree mapping, maintenance signals, upgrade impact
  testbot/
    test-runner.md      - running suites, downstream consumers, canary apps
    test-generation.md  - generating tests from usage patterns and coverage gaps
  docbot/
    docs-generation.md      - API docs, changelogs, migration guides from code
    metadata-maintenance.md - CITATION.cff, FUNDING.yml, REUSE compliance
  perfbot/
    performance-analysis.md - anti-patterns, benchmarking, bloat detection

Each skill file describes what the capability is, how the bot uses it, and what tools or approaches it relies on. The shared skills are things every bot needs. The bot-specific skills are the domain expertise that makes each bot's perspective distinct.

Not currently — docbot handles the metadata side (checking license files exist, REUSE compliance, license headers) and forkbot checks license compatibility before forking. But those are both surface-level checks.

A dedicated license bot could go deeper: verifying every file has correct headers, checking that dependency licenses are compatible with each other, flagging license changes in upstream updates, generating proper SPDX expressions, catching the subtle stuff like "this file was copied from a GPL project into an MIT package."

Want me to add one? It's the kind of thing where the boring-but-useful version (headers, compliance, REUSE) is easy to get right, and the harder version (compatibility analysis across the dependency tree) is where it gets genuinely valuable.

Now let me pull the license/REUSE stuff out of docbot since licensebot owns that now.

And update plan.md to include licensebot.

Done. Licensebot gets his own persona file and a license-compliance skill. Pulled the REUSE/license stuff out of docbot's tasks and metadata skill so there's no overlap. Docbot still handles CITATION.cff, FUNDING.yml, and general metadata — licensebot owns everything about actual license correctness and compliance.

Looking at the current lineup, the main gap I see is CI/build infrastructure. Forkbot sets up initial CI scaffolding, but nobody owns it after that. Who makes sure the package builds across multiple runtime versions? Who updates the CI config when a GitHub Action is deprecated? Who notices that the build matrix should include Node 22 now?

A buildbot could own:

• Build matrix (which language/runtime versions to test against)
• CI config maintenance (pinned actions, deprecated features)
• Cross-platform build verification
• Build reproducibility
• Keeping build tooling up to date (bundler version, npm version, etc.)

Beyond that, I think the current seven cover it well. You could argue for an i18n bot or an accessibility bot but those are niche enough that they'd be idle most of the time on backend/library packages.

The other direction is consolidation — perfbot is the weakest of the bunch. Its tasks overlap with testbot (benchmarking) and depbot (unnecessary dependencies). If you wanted to stay lean for the prototype you could fold perfbot's concerns into those two and add it later if the gap shows up in practice.

So: maybe add buildbot, maybe drop perfbot for now. Or keep the roster as-is and see what the prototype tells you. Want me to create buildbot?

Done. Eight bots now:

• Forkbot — administration, process, lifecycle
• Securibot — vulnerabilities, signing, supply chain
• Depbot — dependency graphs, upgrades, maintenance signals
• Testbot — test suites, downstream compatibility, canaries
• Docbot — documentation, metadata, changelogs
• Perfbot — performance patterns, benchmarks, bloat
• Licensebot — license compliance, REUSE, compatibility
• Buildbot — CI, build matrix, tooling, reproducibility

Let me update the devlog skill and the bot personas to reflect that.

Now update the standup skill to match.

Now update the plan.md infrastructure section to include the shared repos.

Good. Now let me address your feedback. Several good points — let me handle them.

Good feedback. Let me add licensebot and buildbot to the bot summaries in plan.md, add the cold-start cycle instructions, and add priority heuristics per bot.

Now add the cold-start cycle to each bot's persona file. Let me do them all in parallel.

Let me add the cycle instructions to each bot persona. I'll add it as a section after the role description in each file.

Done. Three things updated:

1. plan.md now has licensebot and buildbot persona summaries, plus a "Bot cycle" section with the cold-start sequence and per-bot priority heuristics.

2. Every bot persona file now has a "Cycle start" section with the exact steps to follow at the beginning of each run — read devlog, read tracking issues, check standup, check labelled issues, prioritise, work, write devlog, post standup.

3. Devlogs and standups are now issues on shared repos rather than files, which was your earlier ask. The devlog repo and standup repo are both in the infrastructure checklist.

The feedback about starting with Ruby — I'd resolve that open question now and just pick Ruby. You'll spot bad output immediately and you know which gems are critical-but-neglected.

Let me resolve that open question in the plan.

Now let me update the ecosystems skill to be specific about how we'll use the API.

Now let me check what the API actually looks like so the skill doc is accurate.

There's a /critical endpoint and a critical boolean filter. Let me update the skill doc.

Updated. The ecosystems skill now documents the actual API including the critical boolean filter and the /critical and /critical/sole_maintainers endpoints. The candidate-finding flow starts with critical=true on rubygems, sorted by dependents, then filters for staleness — which should surface exactly the kind of packages botberg is designed for.

Some of these are actively maintained. Let me filter for the stale ones — packages where the last release is old.

Now those are interesting. Let me get more detail on the top candidates.

Here's what stands out:

For a first botberg target, simplecov or rest-client seem best. Simplecov has the most dependents by far and enough open issues to give every bot real work. Rest-client is more stale but the codebase is probably messier after 6 years of drift.

Simplecov might be the ideal first package — MIT license, huge dependent count, active enough that someone might actually notice the fork, but clearly stalled on releases despite having maintainers.

What do you think? Or want me to dig deeper into any of these?

Good pick. 13K dependents, 142 open issues, no release in over three years despite having 7 listed maintainers. Plenty for every bot to sink their teeth into.

Next step is getting Forgejo running locally and setting up the accounts. Want to start on that?

Docker's running. Let me set up a docker-compose file for Forgejo and start a config log.

Mapped to port 5000 now. Ready to start it?

5000 is taken too. Let me check what's free.