| name | babysit-pr |
| description | Autonomously monitor and fix PR CI failures. Trigger on 'CI is red', 'fix CI', 'babysit this PR'. |
| origin | Orchestrator — earned through direct practice (see commit history) |
| source_version | 2026-04-18 |
babysit-pr — Autonomous PR Monitoring
You are babysitting a pull request. Your job is to watch CI checks, and if any fail, diagnose and fix them.
Inputs
The user provides a PR number or URL. Extract:
- Repository (default: current repo)
- PR number
Loop
Repeat up to 5 rounds:
1. Check CI Status
gh pr checks <PR_NUMBER> --json name,state,conclusion
If all checks pass → report success and STOP.
If any check is "in_progress" → wait 60 seconds and re-check (max 3 waits).
If any check failed → proceed to step 2.
2. Read Failure Logs
gh run view <RUN_ID> --log-failed
Extract the error message, failing test name, and relevant context.
3. Diagnose
Read the failing file(s). Understand why the test/lint/build failed.
Apply the Surgical Changes principle: fix ONLY the failure, don't clean up adjacent code.
4. Fix and Push
Make the minimal fix. Commit with message:
fix(ci): <what was fixed>
babysit-pr round N/5
Push to the PR branch:
git push
5. Wait and Re-check
Wait 60 seconds for CI to restart, then go back to step 1.
Safety Rules
- Max 5 rounds. If CI is still red after 5 fix attempts, report the remaining failures and STOP.
- Never force-push. Only regular push.
- Never modify CI config (.github/workflows/) to make tests pass. Fix the code, not the tests.
- If the failure is infrastructure (timeout, runner unavailable, rate limit), report it and STOP. Don't try to fix infra.
- Each fix must be a separate commit with a clear message. No squashing.
Common Rationalizations
These thoughts mean you're about to violate the babysit protocol:
| Rationalization | Reality | Correct Behavior |
|---|
| "This test is flaky, I'll just re-run" | Flaky tests have root causes. Re-running without diagnosis is coin-flipping. | Read the failure log. If truly flaky (timing, network), report it as infra. Don't retry blindly. |
| "I'll fix the test to match the new behavior" | You're making the test pass, not making the code correct. Tests define expected behavior — code should conform. | Fix the code, not the test. Unless the test expectation is genuinely wrong. |
| "This is just a lint warning" | Lint rules exist because someone shipped a bug that rule would have caught. | Fix the lint issue. Don't disable the rule. |
| "Let me also clean up this file while I'm here" | Babysit scope is CI fixes ONLY. Mixing cleanup with fixes makes rollback impossible. | Fix the failure. Nothing else. |
| "The CI config is wrong, let me fix it" | Modifying CI config to make tests pass is cheating, not fixing. | Report CI config issues to the user. Don't touch workflows. |
| "Round 5 will definitely work" | If 4 rounds failed, your mental model is wrong. Round 5 with the same model will also fail. | Stop at round 5. Escalate with a diagnostic report. |
Exit Conditions
- All checks green → "PR is green. All checks passing."
- 5 rounds exhausted → "Babysit limit reached. Remaining failures: [list]"
- Infrastructure failure → "CI infrastructure issue: [description]. Manual intervention needed."
- User interrupts → Stop immediately.
Common Rationalizations
| Thought | Reality | Correct Behavior |
|---|
| "The test is flaky, I'll skip it" | You don't know that without evidence. Flaky = same code passes sometimes. | Run the test 2x. If it fails both times, it's real. Only skip with gh run rerun evidence of prior flaky history. |
| "I'll just disable the lint rule" | Disabling rules is modifying CI config — explicitly forbidden above. | Fix the code to satisfy the linter. |
| "This CI failure looks like infra" | Infra failures are timeouts/runner issues, NOT code errors with clear stack traces. | If there's a stack trace pointing to code, it's a code bug. Diagnose it. |
| "Let me refactor this while I'm here" | Surgical changes: fix ONLY the failure. Adjacent cleanup is scope creep. | Fix the one failing line. Commit. Move on. |
| "5 rounds isn't enough, I need more" | 5 rounds is the hard limit. If you can't fix it in 5, the problem is your diagnosis, not the round count. | Report remaining failures honestly. Don't request more rounds. |
| "I'll batch these 3 fixes into one commit" | Each fix = separate commit. Batching defeats bisectability. | One fix, one commit, one push. |
