You are babysitting the current branch's pull request: keep it mergeable. Watch it, fix what blocks a merge, and keep going. Run unattended — do not stop for confirmation between rounds, and do not self-terminate when the PR is clean; keep watching until the user stops you.
The narrow case (waiting on an AI bot review you requested) is just this loop on a PR where CI is already green and the branch is current — it collapses to the comment step.
-
Find the PR for the current branch. If there is no PR, stop and tell the user — there is nothing to babysit.
-
Start the monitoring loop — always, and before assessing anything. Invoke the loop skill (/loop, self-paced or with an interval) to run the per-round cycle (steps 3–8) on a sensible cadence. Start it unconditionally: do this even if you expect or already know the PR is currently mergeable. A clean PR is not a reason to skip the loop — it can regress at any time (new commits land on the base, a reviewer or Copilot comments, a check re-runs and goes red). The only thing that stops the loop is the user. Do not assess first and bail early because it looks clean; establish the loop, then let each round assess. At the very start of each round — including when a scheduled wake-up fires — check the conversation history for a stop request (a /babysit-stop, or the user asking to stop/halt/cancel babysitting) made since this loop started. If you find one, the user stopped babysitting: do nothing, do not schedule a new wake-up, briefly say babysitting is stopped, and end (see the babysit-stop skill).
A wake-up-driven round is a continuation, never an explicit restart. When this round was triggered by a fired wake-up — the turn input arrives prefixed as /loop /babysit-pr rather than a bare /babysit-pr, and/or you see a "resuming /loop wakeup" marker — it is a loop continuation, not a fresh user start. It is fully subject to the stop check above and must self-terminate if a stop exists in history. Do not treat it as the user re-starting babysitting, and do not let it "supersede" an earlier stop. Only a bare, user-typed /babysit-pr (no /loop prefix, no wake-up marker) counts as an explicit resume that begins a new loop.
-
Assess the merge state (once per round, inside the loop). Determine: CI status (per check), whether the branch is behind or conflicts with its base, and what review comments are open (inline review comments, top-level reviews, issue-style PR comments) from both AI bot reviewers and humans. Skip resolved/outdated threads. If nothing is actionable this round, that is a normal clean round — report briefly (step 8) and let the loop continue; do not exit.
-
Fix CI if any check failed or was cancelled:
- Invoke the
ci-failure skill with --fix to triage and apply confident fixes.
- If it produced working-tree changes, invoke
commit-commands:commit to commit, then push.
- If it produced no changes (flake, infra/config, or pre-existing on the base branch), do not commit. Re-run the failed checks if they look like flakes; otherwise note it for the report — it needs the user's judgment.
-
Sync with base if the branch is behind or conflicts with main/master:
- Merge the base branch in. If it merges cleanly, commit (if a commit is needed) and push.
- If it conflicts, invoke the
merge-conflict skill with --fix to resolve the hunks it is confident about, then stage, complete the merge, and push. Leave any hunks it flagged as needing judgment for the report — do not guess on semantic conflicts.
-
Address review comments if any are open:
- Invoke the
pr-feedback skill with --fix to verify each point adversarially and apply the ones that survive refutation.
- If it produced working-tree changes, commit and push them.
- For each thread it addressed, post a concise reply noting what changed, then leave the thread open — do not resolve it. This applies to both AI bot threads (Copilot, CodeRabbit, Cursor, Graphite, Gemini Code Assist, or any automated reviewer) and human threads: reply only, and leave resolving to the reviewer or the user.
- For points it judged invalid, out-of-date, already addressed, or needing the user's judgment, do not auto-reply or argue with the reviewer — leave the thread open and list it for the report.
-
Let the loop run the next round (back to step 3). Watch the new run triggered by any push, and re-check for comments that landed while you were working (a requested review may arrive mid-round). The loop does not self-terminate — keep babysitting until the user stops you. Guard against thrashing per workstream: if the same CI check, conflict, or comment fails to converge after a couple of attempts (your fix didn't take, or it bounces back), stop pushing more changes at it, leave it for the user, and keep watching the rest rather than looping on a fix that isn't working.
-
Report after each round of activity (and whenever the PR reaches a clean state): summarize the current merge state and, per workstream, what changed this round — CI failures fixed and pushed, base-sync/conflict resolution, comments addressed (fixed and replied to, left open) vs. left for the user — plus anything needing the user's judgment (flakes, infra, semantic conflicts, design-trade-off comments, non-converging fixes). Then keep watching.
