Babysit PR

The repos we work in have AI review bots. They're helpful, even if they are not always right. Treat every bot comment as a hypothesis, not a finding: read the code it points at before acting on it.

First check gh pr view <n> --json isDraft. Review bots skip draft PRs (CodeRabbit posts "Review skipped: Draft detected"), so on a draft there is no bot review to wait for. Either ask the user whether to mark it ready (gh pr ready <n>), or trigger one manual review with a single @coderabbitai review comment. Trigger ONCE and wait: repeat triggers do nothing ("Already reviewed") or hit the fair-usage rate limit, and each attempt leaves a spam comment on the PR. When babysitting several draft PRs, stagger the triggers well apart (the limit is adaptive and shared across the org); expect some reviews to take an hour or more to land, and just wait — re-commenting does not speed it up.

If your harness offers tools to monitor a PR, use them so you can respond when comments arrive. Otherwise, poll: gh pr checks <n> --watch in the background covers CI, and check for new comments on a relaxed interval.

Only act on checks and comments newer than the latest push — anything older is already handled or already obsolete.

For each comment: fix it if it's a real bug. If it's wrong, reply with evidence (file:line, the actual behavior) and resolve the thread. If it's real but beyond the PR's goal, acknowledge it and file a follow-up issue instead. Human reviewers outrank bots — address their requests, and never resolve their threads for them.

For CI failures, read the failing log (gh run view <id> --log-failed). Fix what this PR caused. Rerun a flaky check once (gh run rerun <id> --failed); if it fails again, it's real. If it's broken on the base branch too, report it to the user — that's not this PR's job.

Push fixes as new commits; a reviewed branch keeps its history. Reply to inline comments in their thread, never as a top-level PR comment (gh pr comment can't do this — use GraphQL):

# list threads with resolution state
gh api graphql -f query='query($o:String!,$r:String!,$n:Int!){repository(owner:$o,name:$r){pullRequest(number:$n){reviewThreads(first:100){nodes{id isResolved path line comments(first:10){nodes{author{login} body createdAt}}}}}}}' -F o=<owner> -F r=<repo> -F n=<pr>

# reply in a thread
gh api graphql -f query='mutation($t:ID!,$b:String!){addPullRequestReviewThreadReply(input:{pullRequestReviewThreadId:$t,body:$b}){comment{url}}}' -F t=<thread-id> -f b='<reply>'

# resolve a thread
gh api graphql -f query='mutation($t:ID!){resolveReviewThread(input:{threadId:$t}){thread{isResolved}}}' -F t=<thread-id>

Screenshots and short recordings help when the fix is visual.

Do not let review feedback expand the PR beyond the user's original goal. Address real shortcomings, but avoid scope creep.

If nothing has changed, stay quiet rather than posting filler comments. Stop when the review bots and required checks are green on the latest commit. Merge only when the user explicitly requested it; otherwise report that the PR is ready.