babysit-prs

Babysitting open PRs

The job

Take a named set of open PRs and drive each to landed — green checks, auto-merge armed, conflicts resolved by whoever owns them — while touching nothing you were not asked to touch.

Land through the auto-merge path, almost always. Arm auto-merge and let the required checks and the queue decide; a direct merge_pull_request / gh pr merge skips the queue's own batch build, so a PR that passed its own checks can still break main in a batch nobody built. Green, approved, or small is not a reason to take the direct route.

The one exception is a NARROW fix for a red on main — and there the direct route is mandatory, not optional. A red main blocks every watch-set PR at once, and the queue cannot land the repair while the base it builds against is broken, so a session holding a qualifying fix pushes it straight to main in the same turn, without asking. That push is the whole of the mandate: MERGING a pull request to deliver the same repair stays a hard halt under root CLAUDE.md § Autonomy until the user instructs it, so a repair that exists only as a PR waits for that instruction while you push the equivalent diff. The five conditions Reds § sets still gate the push — a reproduced cause, only the files that cause names, targeted tests passing locally, about 20 lines, and an empty merge queue. Confidence means you reproduced the red and reproduced its repair; a fix you are inferring takes the ordinary route. For an external-outage red (a download host refusing connections) the repair starts FIRST: the qualifying fix is the minimal change that drops the dependency on the dead host — a mirrored source the existing digest pin still verifies, a cached artifact — and a one-time re-run rides alongside it, of the RUN and never its failed jobs, per the ci-triage skill. A prevention PR that cannot cure the live red is never the thing to force-merge. Say in chat which SHA you landed and what proved it.