PR Babysitter Loop
Monitor a pull request until CI is green and review comments are resolved.
What this Loop Engineering template does
Monitor this pull request and drive it to a mergeable state: keep CI green and resolve review comments, without merging.
This is an active pull request. Read the failing checks and review threads before acting. Prefer small, focused changes.
When to use it
When not to use it
Validation checks
Boundaries & stop rule
Copy the loop prompt
/goal Monitor this pull request and drive it to a mergeable state: keep CI green and resolve review comments, without merging.Task type: PR ReviewTarget tool: Claude CodeWork toward this goal until all validation checks pass or the stop rule is reached.Design hypothesis:This pr babysitter loop can produce a safer result if the scope stays narrow, validation is explicit, and a checker can reject shortcut work.Smallest useful run:Run one bounded pass on the newest relevant signal before expanding scope or adding a schedule.Loop cycle:1. Discovery — Read the latest signal for this template before acting: CI output, issue detail, review comment, dataset report, or content brief.2. Handoff — Hand the work to one agent in an isolated branch, worktree, or clearly scoped session. Keep final approval with a human.3. Verification — Use an independent review pass to confirm the result, inspect the diff or artifact, and reject shortcut work.4. Persistence — Save a short run note with the signal reviewed, actions taken, validation result, and next recommended step.5. Scheduling — Run manually until the loop is reliable; only then consider a scheduled or event-triggered run.Context:This is an active pull request. Read the failing checks and review threads before acting. Prefer small, focused changes.Validation:All GitHub checks passNo unresolved review comments remainnpm test exits 0npm run lint exits 0Validation evidence:Record the original signal, checks run, final result, changed files or artifacts, and any checker rejection.Independent checker:Use an independent review pass to confirm the result, inspect the diff or artifact, and reject shortcut work.Boundaries:Do not merge without human approvalDo not delete tests to make CI passDo not modify unrelated filesDo not force-push unless explicitly allowedStop rule:Stop when all checks pass or after 5 failed attempts.Maximum iterations: 5Budget:Example only: stop before exceeding the agreed per-run token budget.Human approval:Required before merge, deploy, delete, purchase, or external communication.Fallback:If blocked, summarize failing checks, attempted fixes, and the recommended human decision.Loop Validation Log:- Hypothesis: This pr babysitter loop can produce a safer result if the scope stays narrow, validation is explicit, and a checker can reject shortcut work.- Smallest useful run: Run one bounded pass on the newest relevant signal before expanding scope or adding a schedule.- Expected evidence: Record the original signal, checks run, final result, changed files or artifacts, and any checker rejection.- Actual evidence: [fill in after the run]- Passed? [yes / no / partial]- Feedback: After the run, note what the loop learned, what failed, and what should change before the next pass.- Next step: [stop / adjust the loop / run the next pass]Do not delete tests, bypass checks, or modify unrelated files just to satisfy the validation condition. If blocked, stop and summarize the blocker, attempted fixes, and recommended next action.
Failure modes to watch
Review receipt
This is a bounded review exercise for the template, not a claim about a production deployment.
Scenario
A pull request has one failing unit test and two unresolved review threads after an API response rename.
Baseline evidence
The review starts from the named pull request, the failing test output, the current diff, and the two open reviewer comments; it does not assume that an older green run is still valid.
Validation result
The focused unit test and full project checks pass after a one-file compatibility fix, both review threads have written responses, and the final diff contains no unrelated files.
Shortcut rejected
The loop rejects marking a conversation resolved without answering it and rejects merging merely because CI changed from red to green.
Human gate
A maintainer must confirm that the API compatibility choice matches product intent and perform the merge; the loop may only report that the pull request is mergeable.
Loop Engineering FAQ
No. The boundaries forbid merging without human approval. The loop drives the PR to a mergeable state and stops for a human to merge.