Bolt CI healer

The Bolt CI healer is a DinoAI agent that self-healing triggers when a Turbo CI check fails on a pull request: it classifies the failure (pre-commit/lint or dbt build error), applies a fix, and pushes a commit straight to the PR’s own branch. A loop-guard caps it at one fix attempt per distinct error, so it pushes when a fix is genuinely needed and escalates to a human instead of looping when it has already tried.

Prerequisites

Slack connected (self-healing and the agent’s progress run in the configured channel).
A connected Git provider (GitHub, GitLab, or Azure DevOps) so the agent can push a commit to the PR branch.
Familiarity with programmable agents and Bolt self-healing.

Estimated time: 20 minutes.

Steps

Create the agent

In the Agent app, open Agents, select New agent, and start from the bolt-ci-healer template (or Start from scratch). Fill in the builder fields with the content below, then select Deploy and choose Open a pull request: self-healing selects agents from .dinoai/agents/*.yml on the schedule’s git branch, so the agent definition must be merged there. See Build an agent in the UI for a tour of the builder. (Prefer YAML? The PR the builder opens contains the file, .dinoai/agents/bolt-ci-healer.yml, which you can edit by hand from then on.)Name: bolt-ci-healerRole:

Turbo CI Recovery Specialist focused on getting failing CI checks on
open pull requests back to green — pre-commit / lint failures and dbt
build errors.

Goal:

When a Turbo CI check fails, get the PR back to green with the
smallest possible change pushed directly to the PR's own branch.

Follow this recover-or-escalate flow:
1. Fetch the logs of the failed CI run and extract the exact error
   message.
2. Classify the failure:
     - PRE-COMMIT / LINT  → a pre-commit hook failed (e.g. sqlfluff,
       formatting, yaml-lint, trailing whitespace).
     - DBT ERROR          → the dbt build/compile step failed
       (compilation error, failing test, missing ref, broken model
       SQL).
3. Resolve the pull request and branch this CI run belongs to.
4. Inspect prior CI-healing attempts for this branch (from the
   initial context block) and the recent commits already on the
   branch.
5. If the SAME error was already addressed by a prior healing commit
   AND the check is still failing the same way, STOP — do NOT push
   again. Pushing a second time would re-trigger CI and risk an
   endless heal loop. Instead, post a Slack message explaining the
   fix attempt did not resolve it, link the commit, and ask a human
   to take a look.
6. Otherwise, apply the fix:
     - PRE-COMMIT / LINT  → run the project's autofixers (e.g.
       `pre-commit run --all-files`, `sqlfluff fix`), then stage the
       resulting changes.
     - DBT ERROR          → make a surgical edit to the offending
       model / macro / schema yml that resolves the specific error.
   Commit the change to the PR's branch with a clear message
   referencing the CI run, push, and post the commit link. Turbo CI
   re-runs automatically.

Backstory:

You know dbt and pre-commit tooling deeply, prefer surgical edits
over rewrites, and always cite the failing command's error message in
your reasoning. You commit ON TOP of the existing branch — you never
force-push and never rewrite a contributor's history. You are
disciplined about loops: you make at most one fix attempt per
distinct error, and if that attempt doesn't clear the check you hand
it to a human rather than pushing again. You never open a new PR —
the PR already exists, so the fix belongs on its branch.

Model: leave Auto selected.Allowed tools (everything else is refused, see the Tools Reference):

read_file, search_files_and_directories, ripgrep_search
run_sql_query
list_pull_requests, read_pull_request
get_bolt_run_logs
run_terminal_command

The tool allowlist is deliberately narrow and deliberately excludes PR creation: read access, CI observability (get_bolt_run_logs), PR awareness (list_pull_requests, read_pull_request), and a terminal to run the autofixers and git commit/git push to the PR branch. There is no create_pull_request, because a CI failure already has a PR, so the fix is committed to that branch, not a new one. No Slack tool is needed either, because self-healing already threads the agent’s output into the channel.

Enable self-healing on the Turbo CI schedule

Point your Turbo CI schedule’s self-healing at this agent, from the UI or as YAML. See Set up self-healing for the walkthrough. The agent_name must match a .dinoai/agents/*.yml merged on the schedule’s git branch:

paradime_schedules.yml

schedules:
  - name: turbo ci
    description: Turbo CI checks on pull requests
    environment: production
    git_branch: main            # base branch CI builds against
    trigger_on:
      pull_request: true
    commands:
      - pre-commit run --all-files
      - dbt build --select state:modified+
    turbo_ci:
      enabled: true

    notifications:
      slack_channels:
        - channel: '#data-alerts'
          events:
            - failed
        - channel: '#agent-demo'
          events:
            - failed

    self_healing:
      enabled: true
      slack_channel: '#agent-demo'
      agent_name: bolt-ci-healer

self_healing.slack_channel must also appear in this schedule’s notifications.slack_channels, or the deployer rejects it. The agent threads into the existing CI failure notification, so that notification has to exist.

Watch the first heal

Open a PR that deliberately breaks CI, such as an unformatted model (pre-commit) or a model with a bad ref() (dbt). The next time Turbo CI runs and fails, open the failure thread in your self-healing channel. You’ll see the healing session start, the flow run (CI logs, then failure class, then target branch, then prior attempts), and either a commit link pushed to the PR’s branch (which re-triggers Turbo CI automatically) or an “already tried this, needs a human” escalation when the loop-guard trips.

On a fresh CI failure, the agent pushes a fix commit to the PR branch and posts the link in the thread; Turbo CI re-runs on the new commit. On a repeat of an error a prior healing commit already addressed, it posts an escalation instead of pushing again. Once CI goes green, review and merge the PR as normal.

How the loop-guard works

The loop-guard is what makes this agent safe to leave running unattended on every PR. Because a CI fix is itself re-tested by CI, a naive healer could push, fail, heal, and push forever. The guard caps the agent at one fix attempt per distinct error and is driven by three pieces of context the agent reasons over:

Input	Source	Answers
Current CI error	`get_bolt_run_logs(run_id=<failed CI run>)`	What is failing right now, pre-commit/lint or a dbt error?
Target PR / branch	`list_pull_requests` / `read_pull_request`	Which branch do I commit the fix to?
Prior CI-healing attempts	Context block Paradime prepends when the branch has prior healing sessions, plus the recent commits already on the branch	Have I already pushed a fix for this exact error on this branch?

The agent stops and escalates instead of pushing another commit only when both hold: the current error matches an error from a prior CI-healing attempt on the same branch, and a healing commit addressing that error already exists on the branch while CI is still failing the same way. If either fails (the error is genuinely new, or the prior attempt cleared and a different check is now red), it proceeds with the fix.

Paradime injects a “Prior CI-healing attempts for this PR / branch” block into the agent’s prompt automatically when prior sessions exist for the same branch. That is what gives the agent recall across CI re-runs without a memory tool, and it is exactly what the loop-guard reads to decide whether it has already tried.

Next steps

Set up self-healing

Enable self-healing on a Bolt schedule.

Bolt pipeline healer

The same pattern for failed scheduled runs.

Build an agent in the UI

Create this agent visually instead of by hand.

Programmable Agents reference

The agent YAML schema and tools.

Foundations

Automate with AI agents

Set up & configure

Orchestrate data pipelines

Migrate to Paradime

Develop in Paradime

Learn dbt™

Steps

How the loop-guard works

Next steps

Set up self-healing

Bolt pipeline healer

Build an agent in the UI

Programmable Agents reference

​Steps

​How the loop-guard works

​Next steps

Set up self-healing

Bolt pipeline healer

Build an agent in the UI

Programmable Agents reference

Steps

How the loop-guard works

Next steps