ci-sweeper — the red-main watcher

Watches main's CI and, the moment something goes red, classifies the failure and reports it — flaky noted, real failures get a drafted (not applied) fix recommendation. Ships report-only like every kit in this library; the worktree-fix-and-PR behavior is a promotion this loop earns.

Category: A · Repo maintenance · Heartbeat: schedule/event (CI completion + 10m reconciliation sweep) · Level: L1 (report-only; L2 is the catalog's target level, earned after one watched real run) · Cost: Very high (once promoted — L1 polling and classification alone is cheap)

Quickstart

1. Read LOOP.md — the six parts, the prompt, the limits, the three stops, and
   the Promotion to L2 section.
2. ci-sweeper-state.md is your spine — already committed with an empty
   per-failure register.
3. Claude Code: wire a GitHub event trigger (CI completion on main) plus a
   10-minute cron reconciliation sweep, both pointing at
   .claude/skills/loop-task/SKILL.md. OpenCode: rename
   opencode.json.example → opencode.json, add the AGENTS.md line, wire
   skills/loop-task.md into the Actions event + cron wrapper.
4. Rehearse once, by hand, on a real red build before the trigger ever fires:
   "Run the ci-sweeper skill now on the current failing run, exactly as the
   event would."
5. Grade the rehearsal with the loop-verifier agent. PASS → arm the trigger
   at L1. FAIL → fix the skill, never the report.
6. Only after a human has watched one real L1 cycle succeed: consider
   promoting per LOOP.md → Promotion to L2 (worktree fixes, opened PRs, the
   retry-then-blocked bound, a raised token cap).

What's in this kit

Loop Ready checklist

• Provable success condition — ci-sweeper-report.md has a classified entry with a suggested fix for every new failure
• Run limit — 40 runs/day at L1
• Spine written first, committed empty
• Report-only (L1) start — writes only the report + spine + log, like every kit in this library
• Human gate placed — you read the report and decide whether to apply the fix, and separately whether to promote the loop
• One log line per beat, no silent runs
• Kill switch — loop-pause-all in loop-budget.md

How this relates to the course

The heartbeat and target level come from the Part V §15A catalog entry, where ci-sweeper also sets the fleet's own priority order — "ci-sweeper > pr-babysitter > dependency-sweeper > post-merge-cleanup > daily-triage (red main blocks everything)." That urgency explains why the catalog targets L2 for this loop, not why it should skip the L1 proving step every kit in this library ships with (kit-state.md; CLAUDE.md rule 4). The promotion design's central safety mechanism — retry once, then a blocked register instead of a third attempt — is infinite-loops.md scenario 1, the doom loop, applied directly: "a per-item retry cap plus the no-progress stop... not try harder." The L2 worktree-isolation and maker–checker shape (full suite + diff-scope verifier, human merges every PR) mirrors the dependency-sweeper worked example — the closest fully-designed sibling loop in this catalog, and the one this kit's promotion path adapts from.

---

Source: Panaversity's Loop Engineering: A Crash Course (S1). Full attribution: resources/sources.md.