Build

Automated code implementation agent

Overview

Build is a fast, focused, code-first agent that implements features by writing code directly in GitLab merge requests. It reads requirements from Linear tickets and MR descriptions, understands the existing codebase, implements changes following your project's conventions, runs verification (lint, build, tests), and commits clean code.

Build follows a strict "never assume, always ask" policy. If any requirement is ambiguous or could be interpreted in more than one way, Build stops and posts clarifying questions on the merge request rather than guessing.

How to trigger

Assign Build to a GitLab merge request, or delegate a task from Linear. Build can also be triggered automatically when Review requests changes on an MR — it picks up the review feedback and implements the fixes.

What it reads

  • Linear ticket description and all comments (when referenced)
  • MR description, diff, and all discussion threads
  • Repository source files via direct file access
  • CI pipeline status, job logs, and error output

What it produces

  • Code commits pushed to the MR branch (conventional commit format)
  • MR updates and replies to discussion threads
  • Status report listing files changed and a summary of the work done
  • Confidence score (0-100%) assessing how fully the requirements are met
  • Test, lint, and build results — Build checks the CI pipeline after pushing and fixes failures caused by its changes

Workflow

Phase 1: Understand the task

Build reads the Linear ticket (if referenced), MR description, diff, and discussions. It reads relevant source files to understand the codebase context. If anything is unclear or ambiguous, it stops and asks — posting questions as MR comments.

Phase 2: Implement

Build reads existing code patterns, makes changes following established conventions, uses TypeScript strict mode (never as any or as unknown), and updates tests when they exist for the changed code.

Phase 3: Verify

Runs the project's lint command, verifies the build compiles, and runs relevant tests.

Phase 4: Commit and push

Stages only the files it changed (never git add -A), commits with conventional commit format, and pushes to the MR branch.

Phase 5: Check pipeline

After pushing, Build monitors the CI/CD pipeline. If any jobs fail due to its changes, it reads the error logs, fixes the code, and pushes again. It repeats until the pipeline passes or identifies the failure as a pre-existing issue.

Configuration

We recommend creating a dedicated GitLab service account for Build with its own Personal Access Token (PAT). This provides a clear audit trail showing which commits and comments came from Build versus human developers. Configure the PAT in your workspace's integration settings. Build uses your workspace's Anthropic API key for Claude.

Status values

in_progress

Build is actively implementing the task.

completed

All requirements implemented and verified.

partial

Build did what it could but some requirements remain unaddressed.

blocked

An external dependency prevents further progress.

needs_clarification

Build has posted questions on the MR and is waiting for answers.

failed

The task could not be completed due to an error.

Code standards

Build follows existing patterns in your codebase. It uses TypeScript strict mode, writes conventional commits, never loosens existing types, and keeps changes focused — one task, one set of changes. It will never push to main/develop directly, never merge, and never force-push.

Limitations

  • GitLab only.
  • Works best with TypeScript and JavaScript, but supports any language present in your repository.
  • Cannot deploy code. Build writes and commits — deployment is your CI/CD pipeline's job.
  • Never resolves GitLab discussion threads. Only humans and Review resolve discussions.