Scaffolder logo

Scaffolder

From a GitLab issue to a reviewed merge request

Two comments on an issue drive the whole path. /spec makes an agent post an implementation plan. /code makes it write the change, run the tests, fix what fails and open a merge request. A second agent reviews that merge request. A person approves the plan and merges — no step skips that. Self-hosted n8n schedules, serialises and reports every run. It runs in production against gitlab.com on our own repositories.

See the Loop Talk About a Build Like This

The Loop

One issue, seven steps. Three of them are decisions for a person.

  1. An issue

    A normal GitLab issue describes the change. Nothing about it is special.

  2. Plan

    /spec You decide

    A /spec comment, with optional extra notes, makes the agent read the repository and post a plan on the issue: the files to change, the approach and the test plan. Not happy with it? Comment /spec again; the latest plan wins.

  3. Build

    /code You decide

    When the plan is right, /code starts the build. The agent writes the change on a branch of its own and follows the approved plan.

  4. Test and fix

    The project's own test command runs. When a test fails, the agent reads the output and fixes the code, up to three attempts. If the tests still fail, the issue gets a comment with the log excerpt instead of a merge request.

  5. Merge request

    Green tests push the branch and open a merge request that closes the issue. The link is posted back on the issue.

  6. AI review

    A separate reviewer agent picks up new merge requests within minutes. It posts inline comments and a verdict on correctness, security and style. A deeper review with a larger model runs on demand.

  7. Merge

    You decide

    A person reads the change and the review, then merges. Nothing merges on its own.

What It Does

Two Commands, No New Tool

Everything happens in comments on the GitLab issues and merge requests your team already uses. A small web form posts the same commands from a phone.

Tests Decide, Not the Model

The code must pass the project's own test command before a merge request exists. For repositories whose tests need a database or other services, the tests run in GitLab CI instead.

Written by One Agent, Reviewed by Another

The reviewer is a separate agent with its own prompt: a quick pass on every new merge request, a deep pass when you ask. Very large diffs are labelled as skipped, not half-reviewed.

Runs on Your Runners

Agents run in containers on your own host or on self-hosted GitLab runners, outbound only. Secrets reach the containers by variable name, never in workflow definitions or logs. One heavy job runs at a time.

How It Is Built

Two agents and an orchestrator. The build agent is written in Python, with LangGraph for the steps and Claude Code in headless mode for the writing. The coding agent is swappable: Claude Code by default, OpenCode or Codex CLI when your organization works with other models. The reviewer is a second agent. n8n ties them together. The control panel is not reachable from the internet, so it polls GitLab instead of receiving webhooks, and reactions and labels on GitLab record what is claimed, done or failed — no extra database.

  1. Poll GitLab
    new commands and merge requests
  2. Pick a lane
    local container or GitLab CI
  3. Run the agent
    plan, code, test, fix
  4. Report
    issue comment, push notification, dashboard

Local lane

The agent runs in a container on the host. The target repository needs no setup. This fits projects whose tests need nothing but the code.

CI lane

n8n starts a GitLab trigger pipeline and follows it to the end. Repositories whose tests need Postgres or other services use the CI that already runs those tests.

n8n Python LangGraph Claude Code OpenCode Codex CLI GitLab CI Docker Prometheus Po11y

How It Differs from Claude in GitLab

GitLab's Claude Code agent and Anthropic's GitLab CI/CD integration turn one mention into one change. Scaffolder adds a plan that you approve before any code is written, a test loop, a separate reviewer and one scheduler for all of it. It also runs on any GitLab, including a self-managed Community Edition on your own servers, without a Premium or Ultimate licence.

What Leaves Your Infrastructure

The prompt context, including the source code the agent reads, goes to the model provider. That is the cost of a hosted model. With OpenCode and a self-hosted model (Ollama, vLLM or llama.cpp), even that stays in house. The orchestration, the repository of record, the secrets and the logs stay on your own infrastructure, and nothing is open to inbound traffic. Po11y, Prometheus and Grafana on the same host show every run.

We Build This Loop for Your Team

Scaffolder runs in production against gitlab.com. We gladly build it for your organization against the Git platform you already use: GitLab (gitlab.com or self-managed), GitHub (github.com or Enterprise Server), Atlassian Bitbucket (Cloud or Data Center), Azure DevOps, Gitea or Forgejo. We set it up on your runners, tune the plan and review prompts to your codebase and conventions, and show your developers how to write issues an agent can build. Tell us about your repositories.

Get in Touch
All projects
Manage cookies