Babysit

Drive a PR to green — goal loop

GOAL: PR #$1 reaches reviewDecision == APPROVED — a fresh approval on the current head commit — with all CI checks green and mergeable == MERGEABLE. Loop until then. A human still does the merge; you never merge.

Repo: the 2nd argument if given, otherwise the current repo (gh repo view --json nameWithOwner --jq .nameWithOwner).

To make it loop until the goal, run me under the loop skill: /loop /babysit $1 (self-paced — each pass does one check-react cycle, then either declares the goal met and ENDS the loop, or continues. You can also run me once for a single review-react pass.)

Operating principles (non-negotiable)

• Verify every finding against the code — do not capitulate. Open the file, run the check, read the diff. A reviewer (QA bot or human) can be wrong. Fix what's real; push back with evidence on what isn't.
• Always answer every review comment with what you did — the fix + commit SHA, or the evidence-based reason you didn't change anything. Never leave one unanswered.
• Never merge. Drive to approval only.
• Never mutate external state to turn a gate green. If a check is red because of live server/environment state you didn't create (a deploy gate, a drift check, someone else's running job), you may diagnose read-only (SSH, logs, dashboards) but NOT delete/modify resources — they may be someone else's live workload. Report the cause and owner, notify the user, and keep looping at a slower pace (~20–30 min) until the state clears or the user intervenes.
• Surgical fixes — minimal, match surrounding style, conventional-commit messages with the repo's Co-Authored-By trailer.

Each pass (one iteration of the loop)

In the snippets below, substitute the PR number and repo you were invoked with literally — don't rely on bash $1/$2 (those are command-template args, not shell positionals).

PR=<pr-number>; REPO=<owner/repo>; ME=$(gh api user --jq .login)
gh pr view "$PR" --repo "$REPO" --json reviewDecision,mergeable,state,headRefName
gh pr checks "$PR" --repo "$REPO"
# latest review from a non-self author (your own reply-comments surface as reviews — exclude them):
gh api "repos/$REPO/pulls/$PR/reviews" --jq --arg me "$ME" '[.[]|select(.user.login!=$me)]|max_by(.id)|{id,user:.user.login,state}'

1. Is there a new review or unaddressed finding since your last pass (a non-self review with id greater than the last you handled, or any open blocking thread)? If yes → run the React protocol below. If no → just re-evaluate the goal.
2. Evaluate the GOAL:
   • Met — reviewDecision == APPROVED (fresh, i.e. a non-self APPROVED review id newer than your last push) and every CI check passes and mergeable == MERGEABLE: report the green light, notify the user, tell them a human still merges, and END the loop (do not schedule another iteration).
   • Not met — state what's outstanding and continue the loop. Pace the next check to when progress is expected: a bot re-review typically lands ~1–3 min after a push, so a short wait (~270s) is right while CI/bot reviews run; use a longer wait if you're blocked on a human reviewer.
3. Guard the green light: whether a push dismisses an existing approval depends on the repo's branch protection (dismiss_stale_reviews) — check before assuming either way. Regardless, avoid pushing cosmetic/non-blocking fixes once approved: every push re-triggers CI + a fresh review, which can flip the verdict. Fix blocking findings; leave nice-to-haves for a moment you're re-opening anyway (e.g. an update-with-base).

React protocol (per review)

1. Fetch the review body + its unresolved inline comments:

   gh api "repos/$REPO/pulls/$PR/reviews/<REVIEW_ID>" --jq '.body'
   gh api graphql -f query='query($o:String!,$r:String!,$p:Int!){repository(owner:$o,name:$r){pullRequest(number:$p){reviewThreads(first:100){nodes{id isResolved comments(first:1){nodes{databaseId path line body}}}}}}}' -f o="${REPO%/*}" -f r="${REPO#*/}" -F p="$PR" \
     --jq '.data.repository.pullRequest.reviewThreads.nodes[]|select(.isResolved==false)|"thread=\(.id) cmt=\(.comments.nodes[0].databaseId) \(.comments.nodes[0].path):\(.comments.nodes[0].line)\n\(.comments.nodes[0].body)"'
   

2. Verify each finding by reading the actual code at the cited file:line. Real bug, or false positive?
3. Real → minimal fix, git commit (conventional + Co-Authored-By), reply on the thread (fix + SHA), resolve the thread.
4. False positive → reply on the thread with the evidence (file:line, command output) for why it doesn't hold; don't change code; resolve only if genuinely refuted/addressed.
5. Push the fixes (batched) — re-triggers CI + a fresh review, which the next loop pass will pick up.

Reply + resolve mechanics

gh api "repos/$REPO/pulls/$PR/comments/<COMMENT_DB_ID>/replies" --method POST -f body="✅ Fixed in <sha>. <what changed>"   # or pushback reasoning
gh api graphql -f query='mutation($id:ID!){resolveReviewThread(input:{threadId:$id}){thread{isResolved}}}' -f id="<THREAD_NODE_ID>"

Adapt to your repo's review bot

If the repo has an automated reviewer (a QA bot posting reviews or commit statuses), learn its shape on the first pass and treat it accordingly:

• Identify which red checks are the bot's verdict vs real CI. A bot often posts its NO-GO as a commit status alongside the genuine CI checks — reacting to it means addressing review findings, not debugging a build.
• Watch for review/CI races. A bot that reviews while CI is still running can post a non-approving review against incomplete state; a clean re-review on stable green usually approves. If it's genuinely stuck clean-but-unapproved, trigger a fresh review (a no-op push or a re-run) — don't spin silently.
• Check whether a re-run re-evaluates live state. Some gates (deploy pre-flight, drift checks) evaluate the environment at run time — a rerun can go red on drift unrelated to your diff, and a transient red can pass later with no code change. Check WHAT failed before assuming your diff caused it.

Guardrails / hard-won gotchas

• gh ... --jq is gojq (not your local jq) — validate emoji/test() filters with real gh when unsure.
• A conventional-title CI gate (if present) checks PR title format + type-vs-files. If it fails, fix the title to match the changed files' type.
• Intermittent gh HTTP 401s (GraphQL endpoints especially) are usually transient local-auth/gateway artifacts, not real auth failure (gh auth status stays clean). Retry once; if it persists on a write, fall back to the REST equivalent.

Done

Goal met → report it, notify the user, remind them a human merges, and stop looping (omit the next iteration).