I hope this article is going to help and inspire thousands of lazy coders with a bunch of open issues in their repos! Ok, if not 1000s maybe 1 or 2.
How I tokenmaxxed 20 subagents to solve all of my GH issues at once… and packaged this into a skill, so you don’t have to!
Yesterday I was talking to my buddy 💼 Emiliano about a Rails 8 App we built last year (ie, two geological eras ago in AI terms) and we decided to rebuild something new from scratch. I’ve also noticed the app had plenty of open issues on GitHub and I thought: lets fix them lightheartedly with Worktrees and agents and ZERO effort on my side; wait, is this even possible? And if it is, should I blog about it?

YES, it is possible, and Antigravity makes it easy! You just need a few guardrails and some smart prompt which you’re welcome to steal (just scroll 2 paragraphs down)!
But let’s not get ahead of ourselves.
Riccardo, what problem are you trying to solve?
If you maintain an old project, you know the drill: you check the repository after a few months and find 20 open issues, dependabot alerts, and minor feature requests piling up. The thought of manually branching, fixing, testing, and opening PRs for each one is exhausting.
You want to solve those 20 issues, but NOT at the cost of actually READING them!
If only AI could safely solve them and, if not, leave the bug documented with a number of thourough questions for me to tackle? I want to wake up tomorrow with only 4 bugs open and some smart questions to “unblock” the agent, and yes, maybe one of them needs manual resolution, I can live with that!

So I had an idea: what if I wrote a single prompt to rule them all? A prompt that would fetch all open issues, spawn a dedicated worker for each, evaluate whether it could be solved autonomously, and then do the work in parallel worktrees! This is a breeze with Antigravity 2.0 as you can read in ✍️ Richard Seroter’s article .

If you’re a follower of mine, this might ring a bell! I just posted another Worktree + Conductor article here:
- 🪨 Orchestrating with Antigravity: A Crescendo of Agents - Part 1
- 🪨 Orchestrating with Antigravity: A Crescendo of Agents - Part 2
This article differs in the sense that it’s LESS Conductor/Spec-Driven and so it’s less guided and more “trying to get things done without bothering the user”. For a very serious project, I encourage you to use 🪨 HITL+Conductor skill as in article 2 instead.
1. My first solution: a prompt
So I started typing this fan-out prompt on Antigravity 2.0 :
| |
Some important notes
Use a SMART, thoughtful model. Today I’ve used Gemini 3.1 pro in high thinking mode for the main agent. You can spare a few pennies for this as it needs to set it up correctly.

Use a Gemini PRo high-thinking mode for the main agent Enable Turbo mode. What’s the worst that can happen in your GH repo? After all, it’s committed and revertable!

We’re off to a great start! But…
Then I thought: this is so amazing, this is gonna change the world, this should be MORE than just a prompt. How do I maintain it? To quote Ali G, “The world is bigger than Staines, and me gotta build a skill for it!”
In 🇮🇹 Italy we say that appetite comes with eating and so why don’t we raise the bar a bit?
2. Let’s make it a SKILL
Who knows me call me “The Master in overcomplication”, which is not a compliment. Since the first version ( #39f9f19 ) I"ve added a bit of script to bring main and subagents “on rails” and add some forensics analysis with timestamps so we can bettere identify what went worng.
To achieve this, I packaged the logic into a new skill
: ghi-fan-out-coding
. The workflow is simple:
- Analyze and Filter: The orchestrator agent reads the GitHub issues and filters out ones that explicitly require human knowledge (or tags them for clarification).
- Fan Out: It invokes subagents, handing each one an issue.
- Isolated Worktrees: Each subagent creates a
git worktreeto avoid stepping on the others’ toes, uses TDD to write failing tests, and then implements the fix. This is a lesson I learnt in the past month and you can read in 🪨 Part 2 . - Pull Requests: When the tests pass, the subagent pushes the branch and creates a PR with a summary of its choices.
Chatting with AGY on SKILL Specs
Spec Driven Development ( SDD , not to be confused with SSD) couldn’t be funnier and more productive! I love how Antigravity makes it easy for you to comment on an Implementation plan (which is an AGY artifact ):

Think about this: my best friend 🇮🇹 Andrea is not a coder and yet he’s building Finance and Hermes stuff every day with Antigravity 2.0 (and speaking Italian on his mike - guess who’s learnt from!).
We’re ready, let’s start!
I’m at Lido degli Estensi, 🇮🇹, coding with A/C on, and having a blast with my agents. Here’s what happened, Jack Bower style:
🪵 09:41 It all started. Here is a quick video of the agents working in parallel:
🪵 10:04 23 minutes later, all subagents but one have finished! Look:

Don’t believe me? Results are visible here .
🪵 10:15 Some missing JSON fields, update skill, rinse and repeat. I should probably write an article about SKILL.md meta-feedback loop and Skill lifecycle.
🪵 11:30 We’re ready to execute the newer version, shiny skill v1.5! ( View on GitHub
)
🪵 12:14 I’ve updated this article for you guys - so now I’m ready for the second pass
Additional iterations
No CLI, no party!
I love having 20 .JSON in my local computer, but I don’t enjoy reading them manually (as a rubyist, I write poems in YAML - not JSON!) that means you can create a UI or a CLI to show you a synoptic. Let’s do it!
| |
A few minutes later, scripts/dashboard.sh is ready and integrated in my repo’s ( Justfile
):
| |
Riccardo, what about Code Review?
Apparently, Gemini was listening to my GEMINI.md which said “do not push” so I found myself with this issue… 20 PRs and the temptation to tell those agents to stop slacking off and just push to main already! I mean, what can possibly go wrong?

Sounds familiar? It’s a FIFO world where the first wins and all the others end with blood on their hands.
So I’ve worked on version 1.5 of the skill where automated review is happening sequentially (yes Im not convinced parallelism would help here - plus reviewing should be faste rthan coding - hopefully).
Skill Second pass: automated review (v1.5)
🪵 12:21 I start this second prompt v1.5.1:
| |

What changed:
- We have a sequential review phase following the main/subagent phase (not parallel to minimize merge/rebase pain).
- We have a few parameters:
- a HITL threshold to tell it “bother me only for important questions” and do 80% by yourself.
- (minor) A harness name to be put in the GHI signature.
.. and it works!
Look how my 15 subagents are tokenmaxxing my Antigravity without breaking a sweat, and nicely populating 15 JSON files I can then review later:
Let’s check my second execution uuid=D70F962C-9A6E-47E7-B3ED-118F450ABF0C:

Wait, who deleted my status folder?
Woops - some overly diligent agent decided to wipe out the whole status folder. Damn it!
- Fix the skill to say don’t do it again, naughty boy!
- Rinse and repeat:
🪵 12:52 Exec v3 uid=471A394C-0CC3-413B-9457-26318ECAE38B
Now the skill updated to v1.5.4.

🪵 12:54 Start with empty slate, third folder:
📊 Agent Status:
- ⏳ ghi-12: Pending
- ⏳ ghi-18: Pending
- ⏳ ghi-23: Pending
- ⏳ ghi-24: Pending
[..]

🪵 13:07 And we’re finished!
$ just show-fanout-execution 471A394C-0CC3-413B-9457-26318ECAE38B
=====================================================
🚀 GHI Fan-Out Bonanza Dashboard | UUID: 471A394C-0CC3-413B-9457-26318ECAE38B
Skill: v1.5.4 #bac8f95
https://github.com/palladius/gemini-cli-palladius-public-goodies/tree/bac8f95/skills/ghi-fan-out-coding
=====================================================
Total Issue Folders Created: 15
Subagents Completed: 15 / 15
PRs Created: 2
Problem Reports (JSON): 0
=====================================================
📊 Agent Status:
🟢 ✅ ghi-12: Completed (Created PR #81) [🕵️ Review: HITL Required]
🔴 🛑 ghi-18: Aborted (NOOP_BAD) (Requires human intervention: Missing credentials. The issue requires the actual GCS_CREDENTIALS_JSON payload to create the Secret in Google Cloud Secret Manager.)
🟢 ✅ ghi-23: Completed (Created PR #87) [🕵️ Review: HITL Required]
🟢 ✅ ghi-24: Completed (Created PR #82) [🕵️ Review: HITL Required]
🔴 🛑 ghi-25: Aborted (NOOP_BAD) (Requires human intervention: Waiting for explicit user approval to push to remote.)
🟢 ✅ ghi-26: Completed (Created PR #78) [🕵️ Review: HITL Required]
🟢 ✅ ghi-27: Completed (Agent 27 forgot to write the json file, fixing it manually.) [🕵️ Review: HITL Required]
🟢 ♻️ ghi-34: NOOP (Good) (Issue #34 is already addressed by PR #62.)
🟢 ♻️ ghi-38: NOOP (Good) (PR #75 is already open and waiting for user manual review and merge. Tests passed. No code changes needed.)
🟢 ✅ ghi-40: Completed (Created PR #84) [🕵️ Review: HITL Required]
🟢 ✅ ghi-41: Completed (Created PR #85) [🕵️ Review: HITL Required]
🟢 ✅ ghi-44: Completed (Created PR #80) [🕵️ Review: HITL Required]
🟢 ✅ ghi-72: Completed (Created PR #83)
🔴 🛑 ghi-73: Aborted (NOOP_BAD) (Requires human intervention: Blocked from pushing to remote by user rule requiring explicit human approval.)
🟢 ✅ ghi-74: Completed (Created PR #79)
=====================================================
As you can see I modernized the emoji report.
Conclusion
My favorite mantra in google SRE is “Automate yourself out of the job” and today I achieved something in that direction.
What used to take an entire weekend of context-switching and tedious git commands now takes 90 seconds of orchestrating. The agents handle the boilerplate, the tests, and the PR creation, leaving me with the fun part: reviewing code and hitting “Merge”.
If you want to try it out yourself, check out the ghi-fan-out-coding skill
!
A few lessons learnt.
- Devil is in the details, some things will always fail. Authnetication,
- For everything else, Playwright is on our side. Here I was able to instruct my skill to login to the app with user and pass in
.env. This might require some preparation and a few iterations..

Do not try this in production. While Agentic AI is fun, I wouldn’t let my agents do the dirty job without HITL unless it’s a playground app or an idea to brainstorm. things do go wrong. For instance, my second execution one subagent decided to wipe out the whole status JSON files, so I had to abort and restart session 3. As an SRE, I’ve asked AGY to write a PoMo so we can learn from it and fix the skill.
AI tries to cut corners. For example I’ve asked for a code quality ratio in v1.5.4 and the executor created a deterministic script which eneded up rating them all 50%


Next steps
Do it with Antigvraity SDK. It would be nice to try out the Antigravity SDK and try to implement this visionary tool: #3 visionary tool . The vision is wild:
python3 run_bonanza.py→ fully automated CLI with real-time guardrails, no human in the loop at all! The SDK would be your “autonomous bonanza launcher” with built-in safety nets. Ullalla! 🚀Nested sub-agents. I’d love to investigate a more complex, nested sub-agents architecture; something like:
foreach i in github_issues(open: True):and then a main agent fixing, another reviewing, another checking for vulnterability, style, etc.. and maybe a last one merging to main and cleaning up after themselves. With multilevel agents possibilities are endless. But wait, does Antigravity support multi-level agents? I’ve tested it for you and YES, it can!


📝 This article will also be published on Medium — link coming soon.
