GitLabWhat they did
Hasanain returned to contributing to GitLab after nine months away and had forgotten the process, so he wrote it down as rules an agent could follow. His kit, gitlab-agent-kit, holds an AGENTS.md whose main rule is that nothing goes out without his approval, eight workflows (onboarding, catchup, scout, analyze, claim, start, ship, followup), eight roles such as issue-analyst, implementer and verifier, a small GitLab API helper so the agent never writes raw API calls, and a per-project playbook with commit formats and lessons from past reviews. A guard script runs before each shell command: it refuses pushes to upstream and reads of the token file, and forces a prompt before any push or GitLab write. During a hackathon week he ran the loop through Claude Code: scout free issues, analyze them in parallel, post a one-line claim, implement with light local checks, write the MR description from the project template, then follow up on review.
How it went
That week produced 20 MRs across 7 GitLab projects. As of October 20, 2026, 15 are merged, 5 are in review and none were closed, and each project has at least one merge. Review threads led to 6 more MRs, 4 of them merged. Most review comments were about project conventions, such as extending an existing test table, and those lessons went into the playbooks. For the write-up he repeated the flow with Antigravity CLI on the GitLab CLI project and it opened 4 MRs, one merged so far.
Worth knowing
Real use changed the kit: claim comments full of plans and questions were cut to one line, three unanswered review comments led to an inbox command, and a heavy local check ran out of memory so the agent now leaves full checks to CI. He notes the rules rely on the agent following AGENTS.md, so permission prompts must stay on. Each MR carries one line disclosing AI use.