Enhancing Bot Automation and Adding Releasebot
Enhancing Bot Automation and Adding Releasebot
Agent
Claude Code
Model
Claude Opus 4.6
Shared
Feb 18, 6:51 PM
Messages2,578
Downloads54
Let me update the devlog skill and the bot personas to reflect that.
That'll inject the actual number (e.g. "When you have used 25 turns") so the bot has a concrete threshold. Stronger than "leave enough" -- it's "stop immediately at turn 25."
The 10-wide Ruby version matrix is brutal -- each version spins up a full Docker container. Let me kill the old upstream workflow runs and just focus on buildbot's leaner matrix (3.1-3.4 only).
4 containers running at once. Let me stop the runner, kill the containers, and then disable the upstream workflows so only buildbot's new workflow runs.
That should quiet things down. The upstream stable.yml is the problem -- it runs 10 Ruby versions per push/PR event. Once buildbot's PR #42 merges (which has a 4-version matrix), we can delete the upstream workflows.
For now, should I disable the upstream workflows on main so the runner isn't overwhelmed when we restart it? Or just leave the runner stopped until #42 is ready to merge?
Right -- PR #48 changes the gemspec's required_ruby_version but doesn't touch the workflow file. The stable.yml workflow has its own hardcoded matrix with all 10 Ruby versions. It'll keep running that full matrix regardless of what the gemspec says.
The fix is either merge PR #42 first (which replaces the workflows), or just delete the upstream workflows on main now. Since they're GitHub-specific anyway and don't belong in the fork, let's just remove them.
Done. The 10-version matrix workflows are gone from main. Once PR #42 merges, it'll add the Forgejo-native workflow with just 3.1-3.4. You can restart the runner now -- it'll be much quieter.
Merged. Forgejo CI is now on main with rspec, cucumber, rubocop, and gem-build as separate jobs across Ruby 3.1-3.4.
Now update the standup skill to match.
Done. Forkbot will now strip the GitHub-specific workflows and set up Forgejo CI as part of the initial scaffolding, so buildbot doesn't have to do it as a follow-up PR every time.
That's basically what you've been doing this whole session -- you noticed the standup problem, suggested benchmarks for perfbot, suggested upstream issue review, spotted the CI matrix waste. You're good at it because you have the full picture and can make judgment calls.
A bot doing this would read devlogs and issues, but it would lack the context to know why something matters. It might say "depbot keeps hitting max turns" but you already knew that and fixed it. The signal-to-noise ratio would be rough.
What might work is a lighter version: not a full bot, but a periodic summary script that forkbot runs at the end of each cycle. She already monitors workload -- she could also flag patterns like:
That keeps it within forkbot's process management role rather than adding another bot. She already reads all the devlogs and standups -- she just needs to be more opinionated about what she sees.
Want me to add that to forkbot's persona, or do you think a separate bot is worth it?
True. And I have context the bots don't -- I can see the logs, change the runner config, edit persona files, adjust turn budgets. A bot watching devlogs would only see the output, not the infrastructure.
Maybe the right move is to formalize what I'm doing as an admin review step. After each cycle run, I (or a script) scan the logs and Forgejo state and flag things for you:
That's a script, not a bot. Want me to write one that runs after run-cycle.sh finishes?
Now add it to the end of run-cycle.sh:
Let me test it:
The turn parsing needs a fix, and there's a minor bug in the admin requests section. Let me clean those up.
The log format uses [error] hit max turns limit and the run summary line isn't being written because the bot hits the limit before the result message. Let me fix the parsing and the admin requests bug.
Now update the plan.md infrastructure section to include the shared repos.
That's cleaner. You can see at a glance that depbot, buildbot, and licensebot missed standup, depbot and licensebot missed devlogs, and 4 bots hit max turns. The CI section shows most failures are from before the network fix.
On your rebasing question -- the bot that authored the PR should rebase it. Each bot already has git configured in their workspace. I'd add it to the shared skills as something every bot should do when their PR has conflicts.
Done. Each bot rebases its own PRs. If conflicts are outside their area (e.g. depbot's PR conflicts with a securibot change), they ask for help rather than guessing.
Sounds good. When it's done, ./cycle-report.sh will give you the summary. The CI should be healthier now that the upstream workflows are gone and the runner network is fixed.
You're right -- depbot already maps the dependency tree and knows which dependencies are problematic. He flagged docile's sole-maintainer risk (#22) and the abandoned apparition (#24). He's the one who knows which upstream packages are load-bearing and which are fragile.
Forkbot should still make the final call (she owns repo creation), but depbot should be the one suggesting candidates based on what he sees in the dependency graph. That's a better signal than forkbot scanning ecosyste.ms cold.
Done. Depbot now suggests fork candidates through admin-requests based on what he sees in the dependency graph. Forkbot still decides, but the pipeline is: depbot spots fragile dependencies, proposes them, forkbot evaluates and sets up the fork.
Good idea. A tea issues create is way shorter than the curl + JSON + python pipeline the bots are writing. Let me check what tea covers.
Tea handles issues, PRs, and labels with --labels on creation (by name, not ID). That alone would save a ton -- no more separate label API calls. Let me register all the bots.
Now let me test it works:
Good. Now let me address your feedback. Several good points — let me handle them.
Now update the system prompt to tell bots to use tea instead of curl. The key differences:
tea issues create --login depbot --repo botberg/simplecov -t "title" -d "body" -L dependencies (one command, labels by name)tea issues list --login depbot --repo botberg/simplecov --state opentea pulls create --login depbot --repo botberg/simplecov -t "title" -d "body" --head branch --base main -L dependenciesNo more JSON, no more python parsing, no more separate label calls.
Now update the turn budget since tea handles labels in one call:
Also update the forgejo skill doc since that's what the bots reference:
Done. The bots will now use tea for issues, PRs, and labels, and only fall back to curl for comments, notifications, and reviewer requests. This should save a lot of tokens per cycle -- a single tea issues create -L dependencies replaces what was previously 3 tool calls (create issue, get label IDs, add labels).
Licensebot is using a mix -- tea for listing issues and PRs, curl for comments and reviews. That's the right pattern. And it's picking up buildbot's review feedback on PR #47 which is good cross-bot interaction.
How's the rest of the cycle going?
Tea has tea pulls approve, tea pulls reject, and tea pulls merge but no direct comment command. Let me check if tea issues edit or the --comments flag helps.
The --comments flag reads comments but there's no tea issues comment command to create them. So the gaps are:
Everything else (create/list/close issues, create/list/merge/approve/reject PRs, labels) works with tea. Let me update the skill doc to list approve and reject too since the bots do PR reviews.
That covers everything tea can do. Comments are the main thing still on curl, and those are unavoidable since tea doesn't have that command.
Ha, it does have comments. Let me check:
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.
Nice. So tea covers comments too. That means curl is only needed for notifications and requesting reviewers.
Also update the system prompt in run-bot.sh:
Now curl is only needed for notifications and reviewer requests. Everything else goes through tea.
That covers notifications too. Curl is now only needed for requesting PR reviewers.
Down to curl for just one thing -- requesting PR reviewers. Everything else is tea.
Yeah, that would close the last gap. For now one curl call for reviewer requests isn't bad. Could also have forkbot handle all reviewer assignment since she's the only one who does it anyway -- then the other bots never need curl at all.
Getting better. Only depbot missed devlog and standup this time (down from 4 last cycle). 6 open PRs now, bots are reviewing each other's work.
Some things to note:
1 pass results on #48 and depbot's branches suggest the fix is working for at least some jobs. Still a lot of legacy failures polluting the view.Want me to bump depbot's turns, or should we try a cycle with the stronger turn-counting instruction that went in after his last run?
The stronger turn-counting instruction ("stop at turn 25") should be in effect now. Let's see if depbot finally makes it to standup this time. Run ./cycle-report.sh when it's done.
Forkbot is on fire. Merged 3 PRs, closed resolved issues, assigned reviewers, flagged testbot as a bottleneck, posted devlog and standup with turns to spare. And using tea for merges and comments now.
Securibot is doing solid work too -- reviewed and approved PR #50, now building out the signing/SBOM infrastructure for issue #3. That's a graduation blocker so it's the right priority.
The tea adoption is already visible. Forkbot used tea comment, tea pulls merge, tea issues create. Securibot is still mostly on curl though -- old habits. Should improve next cycle once it sees the updated system prompt.
From the report, the range is roughly:
The orientation phase is ~8-10 turns for every bot regardless. So a bot with 30 turns has about 20 for actual work. If it's opening 2 PRs (clone, edit, commit, push, create PR = ~5 turns each), plus reviews and comments, 30 is tight.
Your idea about a machine-readable status file is good. If forkbot wrote a status.json per repo after each cycle -- open issues by label, PRs waiting on each bot, what merged since last update -- the other bots could read one file instead of making 8 API calls to orient. That'd claw back 5-6 turns per bot per cycle.
Want me to add that to forkbot's responsibilities?
Now add the cold-start cycle to each bot's persona file. Let me do them all in parallel.
Now update the cycle start instructions for all the other bots to read it. Let me update the shared section in run-bot.sh since that's where the cycle instructions live.
Done. Forkbot writes status.json at the end of each cycle, other bots read it at the start. Should cut orientation from ~8-10 turns down to 2-3 (read status.json + check notifications).
The runner image catthehacker/ubuntu:act-latest is based on Ubuntu 20.04, which is too old for Ruby 3.2+. The ruby/setup-ruby action only has prebuilt binaries up to 3.1 for that OS.
We need a newer base image. Let me check what's available.
There's catthehacker/ubuntu:act-22.04 which should have Ruby 3.2-3.4 support in setup-ruby. Let me update the runner config.
Runner registered and picking up tasks with the Ubuntu 22.04 image. That should have Ruby 3.1-3.4 available in setup-ruby. First image pull will be slow but after that it'll be cached.
Switched to catthehacker/ubuntu:act-22.04. Ruby 3.1-3.4 should all have prebuilt binaries now. The first run will pull the image (~1.5GB) so it'll take a few minutes, but after that it's cached.