GitHub Event Loop: Auto-Respond to CI and PRs

The GitHub Event Loop connects SuperBuilder to your GitHub repository and automatically spawns AI agents in response to events. CI failure? An agent starts fixing it. New bug filed? An agent investigates. PR opened? An agent reviews it. All without you having to initiate anything.

What Events Can Trigger Agents

SuperBuilder listens to GitHub webhook events and can trigger agents on:

CI failures — when a GitHub Actions workflow fails on a branch or PR, SuperBuilder spawns an agent to investigate the failure, read the logs, and attempt a fix. If the fix passes CI, it pushes the changes.

Issues filed — when a bug report or feature request is opened, an agent can triage it: reproduce the issue, identify the relevant code, and leave a comment with findings or an initial fix.

Pull requests — when a PR is opened or updated, an agent reviews the changes, checks for common issues, and leaves a structured review comment.

PR comments — when someone leaves a review comment requesting changes, an agent can respond and implement the feedback automatically.

Deployments — when a deployment completes (or fails), trigger an agent to run smoke tests, update documentation, or send notifications.

How to Set It Up

1. Install the SuperBuilder GitHub App on your repository from the SuperBuilder dashboard
2. Configure which events should trigger agents and which branches to watch
3. Set the agent prompt template for each event type
4. Set budget limits and approval requirements

Once configured, SuperBuilder listens to your repo's webhooks and acts on events automatically.

CI Failure Recovery

CI failure handling is the most commonly used event loop feature. Here's the typical flow:

1. A commit is pushed to a PR branch
2. GitHub Actions runs and fails
3. SuperBuilder receives the failure webhook
4. An agent reads the workflow logs to understand what failed
5. The agent reads the relevant code and identifies the cause
6. The agent makes a fix and pushes it to the PR branch
7. GitHub Actions reruns
8. If it passes, the agent leaves a comment explaining what it fixed
9. If it fails again, the agent tries again (up to your configured retry limit) or flags it for human review

For teams with flaky tests, noisy CI, or frequent breakage, this loop saves enormous amounts of time.

Pull Request Review

When a PR is opened, the Event Loop can automatically:

• Check for obvious issues (missing tests, console.log left in, insecure patterns)
• Verify that the changes match the PR description
• Run any custom checks defined in your project's SOUL configuration
• Leave a structured review with inline comments

This isn't a replacement for human review — it's a first-pass filter that surfaces issues before a human ever looks at the PR. Human reviewers spend their time on what actually matters.

Issue Triage

When a bug report is filed, the Event Loop can:

• Search the codebase for the code path described in the issue
• Attempt to reproduce the issue based on the description
• Leave a comment with initial findings: "Found the likely cause in auth/middleware.ts:42"
• Create a fix branch if the issue is straightforward

Issues get initial triage in minutes instead of waiting for the next sprint planning.

Approval Gates

Not every event should trigger an agent without human sign-off. You can configure approval gates:

• Always run — for events you trust (like CI failures on dev branches)
• Notify first — agent drafts a plan, you approve before it runs
• PRO-only events — some event types require explicit activation per repo

Approval gates let you start conservatively and loosen the leash as you see how the agents perform on your specific repo.

Budget Controls

The Event Loop respects your budget settings. You can set:

• Max cost per event — if an agent run would exceed this, it stops and notifies you
• Daily event budget — total spend cap per day for event-triggered agents
• Model configuration — use a cheaper model for routine CI fixes, and a more capable model for complex issue triage

Practical Example: Never Manually Fix CI Again

For a typical team, CI failures are a constant interrupt. Someone pushes, CI breaks, Slack pings someone, they stop what they're doing to investigate, push a fix, wait for CI again. Half an hour gone.

With the Event Loop:

1. CI breaks at 2pm
2. SuperBuilder agent starts at 2:01pm
3. Agent fixes the issue and pushes at 2:08pm
4. CI passes at 2:14pm
5. PR author gets a comment: "Fixed failing test in auth.test.ts — incorrect mock setup after the recent auth refactor."

No interrupts. No context switching. The developer reviews the fix in 30 seconds and moves on.

Frequently Asked Questions

Does this work with any CI system?

SuperBuilder uses GitHub webhooks, so it works with any CI system that reports status to GitHub — GitHub Actions, CircleCI, BuildKite, and others.

Can I limit which branches trigger agents?

Yes. You configure which branches (or branch patterns like feat/*) trigger the event loop. Main branch, all PRs, specific branches — your choice.

What if the agent makes things worse?

Agents push fixes to existing PR branches, never directly to main. The worst case is a broken PR branch, which is the same situation you started from. You review all agent-pushed commits before merging.

Can I review what the agent is going to do before it does it?

With approval gates enabled, yes. The agent plans its approach and sends it to you for approval. This is the recommended configuration when starting out.

How do I handle repos with complex CI pipelines?

You can provide the agent with context about your CI structure in the configuration — what different test suites mean, which failures are known flaky tests, which workflows are optional. The more context you give, the better the agent performs.