gitlab-contribution

July 9, 2026~3 minArchived

Why I built this

Signal

Most GitLab contributor guidance assumes a GitLab Development Kit. Mine was a language model working from disposable cloud VMs, and I wanted what it landed to be verifiable: a reproduction on a real instance first, then the issue or merge request, so maintainers read less that is wrong.

Build

One skill an agent could follow from scoping a gap to a merged merge request without a kit: the duplicate check, docs-only merge requests through the API, clone and rebase, the review response. GitLab's own agent skills rode beside it at a pinned commit, and the spine handed them the steps they owned.

Novel

Contribution and reproduction became one workflow for a model. RSpec, psql and Rails console work routed to a throwaway self-managed instance, so the agent verified against GitLab as it runs before asking for review: LLM-mediated simulation pointed at GitLab's own codebase.

Journey

The workflow and the environment kept routing to each other across a repository boundary, and the split turned out to be mine, not the work's. An agent that verifies before it files wants both together, which is where gitlab-simulation keeps them.

gitlab-contribution was a Claude Code plugin for contributing to GitLab projects, above all the gitlab-org/gitlab monorepo, from a machine with no GitLab Development Kit. It carried one authored skill, the contribution spine, beside GitLab’s own agent skills from gitlab-org/ai/skills, vendored at a pinned commit. The spine owned working without a kit and handed commit messages, merge request descriptions, pipeline watching and review to the vendored skills by name. Its environment half, gitlab-simulation, supplies the throwaway self-managed instances the spine routes to.

Contribution path without a GDK

Scoping ends in a duplicate check, because keyword search over a tracker that size comes back clean when it isn’t.
A docs-only change builds its branch, commit and merge request through the API in one call, with no clone.
Code changes work from a worktree on one canonical clone; rebasing goes through a patch, and the MR runs merged results pipelines.
Commit messages and MR titles pass lint-message.sh, transcribed from gitlab-dangerfiles at the version the monorepo pins, so the agent fails locally on the rule Danger would fail it on.
RSpec, RuboCop, psql and Rails console work routes to a simulation VM; the skill never pretends a laptop can run the monorepo.
Review response applies suggestions as a batch and resolves threads in order.

A router reads only the description when it chooses between this skill and the vendored ones, so the description is gated.

Description gated by a routing battery

sims/fire-battery.md holds routing scenarios, each with the skill that should answer it, and a recorded verdict carrying the hash of the description it judged.
A blind router arm, a model with no tools or file access, gets the live index of every shipped skill and picks one per scenario; scoring is against the held answer key.
sims-check.sh runs in CI without a model call: the verdict must read KEEP and the hash must match SKILL.md, so an edited description fails until the battery is re-run.

The skill stops at contribution. Operating or upgrading a running instance belongs to gitlab-simulation’s own skill, and the posture of the self-managed, controlled-egress case is egress‘s.

Created Jul 2026 · Archived Oct 2026

Retrospective →