When you are actively contributing across multiple large-scale open-source repositories—like gitlab-org/gitlab (Ruby on Rails), gitlab-lsp (TypeScript/Go), and ai-assist (Python)—context switching is the biggest bottleneck.
Between checking maintainer emails, stripping out unwanted lines of code, satisfying rubocop / danger-review / ruff, and babysitting long CI/CD pipelines just to hit "Start Merge Train", hours of engineering focus get lost to manual admin work.
So, I built a Zero-Touch Autonomous Pipeline:
GitLab Mail + Antigravity IDE + CodeRabbit + glab CLI = Clean Code Directly on the Merge Train
Here is the exact step-by-step guide on how this workflow operates, what to do once the agent links your GitLab session, and how you can replicate it for your own open-source contributions.
Instead of manually reading emails, switching branches, running linters, and replying to threads, the entire lifecycle is delegated to an autonomous agent inside Antigravity IDE:
glab. rubocop, rspec, ruff, mypy, eslint, jest) and formats commits to pass danger-review (<= 72 chars, imperative mood, proper Changelog: trailers).glab ci status --live. If any job fails, it pulls glab ci trace, fixes the root cause, and pushes again.
When you paste the system prompt into Antigravity IDE, it authenticates your GitLab session via glab and lists your active MRs across all namespaces:
Authentication succeeded and your active GitLab session is now fully linked!
Active Open Merge Requests discovered:
- gitlab-org/gitlab!264864 – Expose list_user_events as MCP tool
- gitlab-org/gitlab!264863 – Add poll_after_seconds hint to MCP get_pipeline
- gitlab-org/gitlab!264862 – Add description_edits to MCP save_work_item
- gitlab-org/editor-extensions/gitlab-lsp!4539 – fix(cli): hold pending wakes
- gitlab-org/modelops/applied-ml/code-suggestions/ai-assist!7642 – fix(dws): read status_code
- gitlab-org/modelops/applied-ml/code-suggestions/ai-assist!7641 – feat(agent-platform): tool-call guard
- gitlab-org/editor-extensions/gitlab-lsp!4536 – fix(workflow-executor): key virtual workspace files
- gitlab-org/gitlab!261030 – Extend Organizations::Organization#empty?
Notice at the bottom that the agent s one last time to ask:
"Which Merge Request would you like to process first?"
Here are the 3 ways you can command the agent from this exact screen depending on your goal.
If you want to watch the agent resolve a single fast-moving repo first (like ai-assist or gitlab-lsp where CI runs in a few minutes), reply with a single command:
Process gitlab-org/modelops/applied-ml/code-suggestions/ai-assist!7642 now. Do not ask for confirmation—run the full maintainer + CodeRabbit fix loop, verify CI is 100% green, and dispatch directly to the Merge Train.
When you have 8+ open MRs across Monolith, LSP, and AI Gateway, you want the agent to sweep through all of them sequentially—starting with quick-win TypeScript/Python repos and finishing with the heavy Rails monolith MRs.
Paste this exact reply into Antigravity:
Process ALL of my open MRs sequentially without stopping for human input, in this exact order:
1. gitlab-org/modelops/applied-ml/code-suggestions/ai-assist!7642
2. gitlab-org/modelops/applied-ml/code-suggestions/ai-assist!7641
3. gitlab-org/editor-extensions/gitlab-lsp!4539
4. gitlab-org/editor-extensions/gitlab-lsp!4536
5. gitlab-org/gitlab!264864
6. gitlab-org/gitlab!264863
7. gitlab-org/gitlab!264862
8. gitlab-org/gitlab!261030
For each MR:
- Fetch all unread maintainer comments and CodeRabbit review threads.
- Checkout the branch, rebase cleanly onto upstream main/master, and remove any unwanted lines of code.
- Run local linters and targeted tests (ruff/pytest, eslint/jest, or rubocop/rspec).
- Push, resolve threads with the fix commit SHA, monitor CI until 100% green, and enroll directly into the Merge Train.
If the agent asked "Which MR would you like to process first?", it means it is waiting for a target pointer. To eliminate even that initial question so it strictly follows your unread emails:
Do not ask me which MR to pick. Scan my unread GitLab notification emails (or sort my open MRs by most recent maintainer comment), automatically select every MR with unresolved reviewer or @coderabbitai threads, fix them one by one, and send them straight to the Merge Train.
While you grab a coffee, here is what Antigravity IDE is executing behind the scenes for each MR:
glab api "projects/:id/merge_requests/:mr_iid/discussions" | jq '.[] | select(.notes[].resolvable == true and .notes[].resolved == false)'
glab mr checkout 264864
git fetch origin && git rebase origin/master
Before any code leaves your machine, it must pass both CodeRabbit's diff hygiene check and GitLab's strict static analysis:
bundle exec rubocop --parallel
bundle exec rspec spec/requests/api/mcp/
yarn lint:eslint && yarn jest
poetry run ruff check --fix . && poetry run pytest
glab ci status --live
glab mr merge 264864 --auto-merge --squash=false --yes
gitlab-org, maintainers often prefer to click "Resolve thread" themselves after verifying your fix. Configure your agent to post a concise reply ("Addressed in <commit-sha> — removed the redundant check and added spec coverage. Ready for re-review!") and only auto-resolve threads generated by bots like @coderabbitai or git diff origin/master...HEAD has a clear purpose.
By connecting GitLab Mail, Antigravity IDE, CodeRabbit, and the glab CLI, you transform open-source maintenance from a manual chore into an autonomous background process. You focus on high-level systems architecture and problem-solving—and let the agent handle the rebase, lint, review fixes, and Merge Train dispatch.
Happy shipping! 🚀