CI Loops for Claude Code: Watch PR Checks Without Babysitting the Terminal

CI Loops for Claude Code: Watch PR Checks Without Babysitting the Terminal

A CI loop moves PR-check polling from you to the agent. You open the pull request, hand the watching to Claude Code, and get interrupted exactly once — when every check is green, or when one is red and the failure log is already in front of you. The alternative is the familiar routine: alt-tab to the CI tab, refresh, three of five checks still running, switch back, lose the thread, refresh again.

The waiting is cheap. The context switches are not. Every trip to the checks tab costs a reload of whatever you were holding in your head, and a 20-minute pipeline can charge that toll six or seven times. Polling is also work a loop handles well: one condition to check (are the checks done?), one action between checks (wait), one stop signal (a terminal state). No step needs a human.

CI loops come in two shapes with different risk profiles:

The passive loop: watch and report

The minimal version is one line:

/loop 5m gh pr checks 1234

That polls PR #1234's checks every five minutes and reports each pass. Watch PR checks pass is exactly this pattern — poll on an interval, stop when the checks settle. Check PR CI status is the same loop at a couple-minute cadence.

The stop condition is where these prompts go wrong. "Until all checks pass" is half a stop condition. Checks also fail, and a loop that only stops on success polls a red build until you notice and kill it. A correct watch loop stops on any terminal state: all green, any check red, or checks that never started. When it stops, it names which state it hit. A failure should interrupt you as fast as a success does.

This gap is not rare. Across the 235 loops published in this directory, only 20% state an exit condition at all — and an exit condition is the entire job of a watch loop (the full grading data).

Match the interval to the pipeline. A 30-second unit suite doesn't need 5-minute polling, and a 40-minute integration run doesn't need 30-second polling that burns turns watching nothing change. The right cadence is the one where most polls land after something actually moved.

The active loop: fix until green

The active loop edits code, which makes it more useful and more dangerous. When a check fails, the agent reads the log, makes the smallest change that addresses the failure, pushes, and waits for the next run. It repeats until the build is green or the budget runs out. Every iteration is a real commit on a real branch, so the bounds below are not optional.

Keep the build green between tasks is this pattern pointed at CI. Run tests until they pass, get the test suite green, and make all tests pass are the same loop pointed at a local suite. The structural difference is where the verification command runs: a build server instead of your laptop. Everything else carries over — the fix step, the budget, the stop.

An active loop needs three guardrails a passive one doesn't:

1. An attempt cap. At most N fixes, then stop and hand back. Five covers most real failures. If five focused attempts don't land, the problem needs a human, and attempts six through twenty just decorate the PR with noise commits. 2. A no-progress stop. Same check, same error, two passes running: the loop is stalled. Report the stall instead of pushing the same fix a third time. 3. A scope limit. Fix the failing check, nothing else. An agent that decides the real problem is your test architecture, and starts refactoring it mid-loop, has left the task. Constrain it to the diff that makes the check pass.

A fix-until-green template

Adapt this directly:

Poll the checks on PR #1234 every 5 minutes. When a check fails, read the failure log, make the smallest change that addresses it, push, and wait for the next run. Fix at most 5 failures. Stop immediately if: all checks pass, the same check fails twice in a row with no change in the error, a fix would require touching more than the failing area, or any check needs credentials or approval you don't have. Report what failed, what you changed, and the final state.

The four stop clauses map one-to-one onto failure modes: success, stall, scope creep, and permission boundaries. Cut a clause and you reopen the matching failure.

Two scheduled relatives are worth knowing. Re-run PR review on schedule re-invokes a review pass on a timer — the same watch pattern applied to review feedback instead of automated checks. Ship specs through code review runs a whole plan-to-PR workflow on an interval.

Failure modes

Four recur:

• Stops only on green. Polls a failed build indefinitely. Fix: define done in both directions.
• No attempt cap. Commit-spams a flaky test. Fix: cap at five and hand back.
• Can't tell "pending" from "failed." Reports a false result while checks are still queued. Fix: require the loop to distinguish terminal states from in-progress ones before it reports anything.
• Credentials to modify required checks. The worst case. An agent that can edit branch protection can "fix" the build by disabling the gate that was protecting you. The template's last stop clause exists for exactly this.

If an overnight pipeline goes red at 3am, a loop that reports to a closed terminal tab tells nobody. ConnectMyEmail gives the agent an email channel for that case. The loop itself needs nothing exotic: a poll command, an interval, and a stop condition that fires on red as well as green.

More CI loops are in the directory, each graded A-F on these exact guardrails, and the Builder generates a full harness around any of them: CLAUDE.md, hooks, an iteration budget, and a fail-by-default evaluator.