Skip to content
Templates/PR Review
PR ReviewMedium risk

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

Long-running pull requests
CI repair
Review comment follow-up

When not to use it

High-risk merges without human approval
Unclear product decisions
Database migrations without rollback

Validation checks

validation
All GitHub checks pass
No unresolved review comments remain
npm test exits 0
npm run lint exits 0

Boundaries & stop rule

!Do not merge without human approval
!Do not delete tests to make CI pass
!Do not modify unrelated files
!Do not force-push unless explicitly allowed
Stop rule — Stop when all checks pass or after 5 failed attempts. If blocked, summarize failing checks, attempted fixes, and the recommended human decision.

Copy the loop prompt

claude-goal.txt
/goal Monitor this pull request and drive it to a mergeable state: keep CI green and resolve review comments, without merging.
 
Task type: PR Review
Target tool: Claude Code
 
Work 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 pass
No unresolved review comments remain
npm test exits 0
npm run lint exits 0
 
Validation 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 approval
Do not delete tests to make CI pass
Do not modify unrelated files
Do not force-push unless explicitly allowed
 
Stop rule:
Stop when all checks pass or after 5 failed attempts.
Maximum iterations: 5
 
Budget:
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

Agent deletes or weakens tests
Agent changes unrelated files
Agent loops on the same CI error
Agent merges without review
Worked scenario review · maintained by TianMingAI · 2026-07-21

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.

Final decisionPartial

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.