| name | babysit |
| description | Watch a PR's CI checks and iteratively fix failures until green. Use after opening or pushing to a PR, or when CI is failing and you want autonomous fix-push cycles. |
| user-invocable | true |
Babysit PR Checks
Monitor CI checks on the current branch's PR and iteratively fix failures until all checks pass.
Constraints
- Max 3 fix-push iterations. After 3 attempts, stop and report what's still failing. Ask the user how to proceed.
- Stop early if: the fix is large/risky, you can't diagnose the failure, or the failure is unrelated to changes on this branch (e.g. flaky infrastructure).
- Push freely within the iteration limit โ no need to ask before each push.
Workflow
1. Confirm there's a PR
gh pr view --json url,statusCheckRollup -q .url
If no PR exists on the current branch, tell the user and exit.
2. Wait for checks to complete
Poll check status until all checks have completed (no pending/in_progress):
gh pr checks --watch --fail-fast
If all checks pass, report success and exit.
3. On failure โ diagnose
Identify which checks failed:
gh pr checks
For each failed check, get the logs:
gh run view <run-id> --log-failed
Read the failure output carefully. Determine root cause before attempting a fix.
4. Fix and push
- Make the fix locally.
- Run any fast local validation that's relevant (typecheck, lint, unit tests) to confirm the fix before pushing.
- Commit and push:
git add <files>
git commit -m "fix CI: <brief description>"
git push
5. Repeat
Go back to step 2. Track iteration count. After 3 fix-push cycles, stop regardless of check status.
Reporting
After each iteration, briefly state:
- What failed
- What you fixed
- Current iteration count (e.g. "attempt 2/3")
When to bail out
Stop and ask the user if:
- The failure looks unrelated to the PR's changes (infra flake, unrelated test)
- The required fix is large or architecturally significant
- You're unsure about the correct fix
- The same check keeps failing after your fix (you're going in circles)
