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) and applies a fix. You choose how the fix reaches the PR:

Commit to the PR branch: the agent pushes a fix commit straight to the PR’s own branch. Turbo CI re-runs automatically.
Open a draft fix PR: the agent checks out a new branch from the branch the failed CI run tested, heals the failure there, and opens a draft pull request against the PR’s branch. The PR description explains the error and how each change resolves it. The PR author reviews and merges it.

A loop-guard caps the agent at one fix attempt per distinct error, so it escalates to a human instead of looping when it has already tried.

	Commit to the PR branch	Open a draft fix PR
Where the fix goes	A commit on the PR’s branch	A new fix branch, with a draft PR against the PR’s branch
Who approves the fix	Nobody before it lands; it shows in the branch history	The PR author reviews and merges the draft PR
CI re-runs	Automatically, on the pushed commit	When the draft PR is merged into the PR’s branch
Best for	Teams that want CI green with no extra step	Teams that do not let bots write to contributor branches, or that want every fix reviewed

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 branch. For the draft fix PR variant, the agent also needs the provider’s CLI in the terminal to open the PR: gh for GitHub, glab for GitLab.
On GitLab: on a workspace connected through the GitLab connection, the agent can push only to its own paradime/<session id> branch. Each session starts on that branch, so use the Open a draft fix PR variant and push the fix from it, instead of creating a new 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.

The Goal and Backstory set how the fix reaches the PR. Select the variant you want:

Commit to the PR branch
Open a draft fix PR

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.

Goal:

When a Turbo CI check fails, fix it on a new branch cut from the
branch the CI run tested, and open a DRAFT pull request against
that same branch. Never push to the original PR's branch.

TARGET BRANCH RULE: the branch you are healing is the head branch
of the PR whose Turbo CI run failed (call it <pr-branch>). The
draft PR's BASE must be exactly <pr-branch>. NEVER open it
against main, the default branch, or the PR's own base branch.
Before creating the PR, confirm the base you are about to pass
equals <pr-branch>; if it does not, stop and fix it.

Follow this recover-or-escalate flow:
1. Fetch the logs of the failed CI run and extract the exact error
   message and the failing command.
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 this CI run belongs to and its head
   branch. This head branch is <pr-branch>, the branch you are
   healing. Note the commit SHA the CI run tested.
4. Loop-guard. List open and merged pull requests whose base is the
   PR branch.
     - If an open fix PR from a previous healing session already
       addresses the SAME error, STOP. Do NOT open another PR. Post
       a Slack message with the existing fix PR link and ask the PR
       author to review it.
     - If a previous fix PR for the SAME error was already merged
       into the PR branch and CI still fails the same way, STOP and
       escalate to a human with both links.
5. Otherwise, check out the PR branch at the tested commit and
   create a fix branch from it, named
   `dinoai/ci-fix/<pr-number>-<short-sha>`.
6. Apply the fix on the fix branch:
     - PRE-COMMIT / LINT  → run the project's autofixers (e.g.
       `pre-commit run --all-files`, `sqlfluff fix`) and stage the
       resulting changes.
     - DBT ERROR          → make a surgical edit to the offending
       model / macro / schema yml that resolves the specific error.
       Re-run the failing command (e.g. `dbt compile` or
       `dbt build --select <model>`) to confirm the fix.
   Commit with a clear message that references the CI run, and push
   the fix branch.
7. Open a DRAFT pull request from the fix branch with <pr-branch>
   (the branch you are healing) as the BASE — not main and not the
   default branch. For GitHub:
   `gh pr create --draft --base <pr-branch> --head <fix-branch>`.
   After creating it, check the PR's base branch and, if it is not
   <pr-branch>, correct it (`gh pr edit --base <pr-branch>`). Title it
   `fix(ci): <short error summary> for #<pr-number>`. Write the
   description with these sections:
     ## CI failure
       Link to the failed Turbo CI run, the failing command, and
       the exact error message in a code block.
     ## Root cause
       What caused the error, in plain language, naming the file and
       line.
     ## Changes
       One bullet per changed file: what changed and why that change
       resolves the error.
     ## Verification
       The command you re-ran and its result, or why you could not
       re-run it.
     ## Next steps
       "Mark ready for review and merge into <pr-branch> to re-run
       Turbo CI on #<pr-number>."
8. Post the draft PR link in the Slack thread, and state that it
   targets <pr-branch>.

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 never push to, force-push, or rewrite a
contributor's branch: every fix goes on its own branch and reaches
the contributor as a draft pull request against the branch you are
healing — never against main — that they choose to merge. You
open at most one fix PR per distinct error, and if that PR is
already open or did not clear the check, you hand it to a human
rather than opening another. Your PR descriptions let a reviewer
understand the failure and the fix without opening the CI logs.

Model: leave Auto selected.Allowed tools (the same for both variants; 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: read access, CI observability (get_bolt_run_logs), PR awareness (list_pull_requests, read_pull_request), and a terminal. The terminal runs the autofixers and git commit/git push. In the draft fix PR variant, it also runs git checkout -b for the fix branch and the Git provider’s CLI (gh pr create --draft on GitHub, glab mr create --draft on GitLab) to open the PR. There is no create_pull_request tool, because standalone agents work with Git through the terminal. 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 see the healing session start and the flow run (CI logs, then failure class, then target branch, then the loop-guard check).

Commit to the PR branch
Open a draft fix PR

The thread ends with 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.

The thread ends with either a link to a new draft PR or an escalation when the loop-guard trips. Open the draft PR: its base is your PR’s branch, not main, and its description explains the CI error, the root cause, and each change. Mark it ready for review and merge it into your branch, and Turbo CI re-runs on the original PR.

On a fresh CI failure, the agent either pushes a fix commit to the PR branch (Turbo CI re-runs on the new commit) or opens a draft fix PR against the PR branch (the PR branch is unchanged until someone merges it). It posts the link in the thread. On a repeat of an error it already tried to fix, it posts an escalation or the existing fix PR link instead of trying again.

Example draft fix PR description

With the Open a draft fix PR variant, the agent writes a description like this:

## CI failure
Turbo CI run 48213 (link to the run) failed on
`dbt build --select state:modified+`:

    Compilation Error in model fct_orders (models/marts/fct_orders.sql)
      Model 'model.analytics.fct_orders' depends on a node named
      'stg_order' which was not found

## Root cause
`models/marts/fct_orders.sql` line 12 references `ref('stg_order')`. The
staging model is named `stg_orders`, so dbt cannot resolve the ref.

## Changes
- `models/marts/fct_orders.sql`: changed `ref('stg_order')` to
  `ref('stg_orders')` so the model resolves its upstream dependency.

## Verification
`dbt compile --select fct_orders` passes on this branch.

## Next steps
Mark ready for review and merge into `feature/orders-mart` to re-run
Turbo CI on #212.

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 fix, fail, and fix again forever. The guard caps the agent at one fix attempt per distinct error.

Commit to the PR branch
Open a draft fix PR

The guard 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.

The guard 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?
PR branch	`read_pull_request`	Which branch do I cut the fix branch from and target with the draft PR?
Existing fix PRs	`list_pull_requests` (open and merged PRs whose base is the PR branch), plus the prior CI-healing attempts context block	Is a fix for this exact error already open, or already merged without clearing CI?

The agent stops when an open fix PR already addresses the same error (it reposts that link) or when a merged fix PR did not clear the same error (it escalates to a human). In all other cases, it opens a new draft fix PR.

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 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

Optimize builds with Paradime State

Migrate to Paradime

Develop in Paradime

Learn dbt™

Steps

Example draft fix PR description

How the loop-guard works

Next steps

Set up self-healing

Bolt pipeline healer

Build an agent in the UI

Programmable Agents reference

​Steps

​Example draft fix PR description

​How the loop-guard works

​Next steps

Set up self-healing

Bolt pipeline healer

Build an agent in the UI

Programmable Agents reference

Steps

Example draft fix PR description

How the loop-guard works

Next steps