●  Agent loops \u00b7 ci failure watcher \u00b7 copy-paste playbook
EST. 20241 makerBuilt in public
Agent loop \u00b7 Ops loop \u00b7 6 steps

CI Failure Watcher
watch it green.

For the red-X morning: the pipeline failed overnight and you want a calm, ordered watch — newest failure first, smallest fix that turns it green, repeat until the whole pipeline passes.

Typical run: 15–60 min typical \u00b7 Copy any prompt box and hand it to your agent as-is.

Loops / CI Failure Watcher

\u00a7 01

When to use

6 steps15–60 min typical
  • CI is red on main or on a release branch and merges are blocked.
  • Failures look spread across jobs (tests, lint, build) and you need an order to work through them.
  • You want the agent to watch and triage without force-pushing over other people’s commits.
  • Re-running a single job is cheap, so polling every few minutes is practical.
\u00a7 02

The steps

one prompt per stepcopy \u00b7 paste \u00b7 run
01Read the pipeline, newest first
Fetch the latest pipeline result for the branch. List each failed job with its name, failed step, and the last 20 lines of its log. Do not fix anything yet — stop after the list.
Why: Old failures mislead — the newest run is the only truth.
02Sort red into kinds
Label each failure: flake-or-infra (timeout, network, runner), test-failure (assertion), or config (lint, types, missing secret). Report the labels with one quoted log line of evidence each, then stop.
Why: Infra flakes, real test failures, and config errors need different responses.
03Retry the flakes once
Retry ONLY the jobs labeled flake-or-infra, one time, with no code changes. Report which jobs turned green and which stayed red, then stop.
Why: A third of red pipelines are weather, not code — retry before you edit.
04Fix the first real failure
Fix ONLY the first remaining real failure. Quote the failing assertion or error, change the minimum code or config to address it, and open no new jobs. Explain the fix in two sentences, then stop without pushing.
Why: Smallest fix for the first real red keeps the branch reviewable.
05Push and watch one cycle
Push the single fix, then poll the pipeline until that run finishes. Report per-job status (green/red) and paste the new failure log if anything is still red. Do not stack another fix until the run completes.
Why: Every push deserves a full watch — partial greens hide downstream reds.
06Confirm green and note it
Wait for a full green run on the branch. Write a 5-line note: which jobs failed, what was flake vs real, what the fix changed, commit hash, and pipeline URL. Keep it under 120 words, then stop.
Why: A green pipeline with no note will be a mystery the next time it reddens.
\u00a7 03

Stop conditions

exit criteria
  • The full pipeline is green on a single run with no retries pending.
  • Every failure from the first read is accounted for as flake (retried green) or fixed (commit linked).
  • The watch note with commit hash and pipeline URL is recorded.
\u00a7 04

Failure modes

what goes wrong + guardrail

Stacking fixes on a moving pipeline

Symptom: three pushes race each other and nobody knows which fixed what. Guardrail: one fix per pipeline cycle — wait for the run to finish before the next push.

Force-pushing over teammates

Symptom: someone else’s commit vanishes mid-watch. Guardrail: never force-push on shared branches; rebase locally and push normally, or hand the loop to a human.

Retrying real failures into green

Symptom: a flaky test passes on retry and the bug ships. Guardrail: a test that fails then passes on retry gets a flake issue filed — retrying twice without a fix is the limit.

\u00a7 05

More loops

5 playbooks
\u2190 All loopsmosaic/lab \u00b7 agent loops