github-pr-babysitter

name

github-pr-babysitter

description

Babysit an open GitHub pull request through automated reviewer feedback loops. Use when the user asks Codex to wait for GitHub PR review bots such as Greptile/Griptile, inspect comments or unresolved review threads, implement and commit requested fixes, push the branch, trigger another review, poll until completion, and keep looping until the review is green, usually a 5/5 confidence score or no actionable comments.

GitHub PR Babysitter

Goal

Drive a PR review loop end to end: resolve the PR, wait for the configured review bot, address actionable feedback, commit and push, request another review, and repeat until the latest bot review is green or has no actionable comments.

Always obey repository instructions first. Read AGENTS.md and any relevant local instructions before editing, running tests, starting apps, or attempting hot reload.

Required Context

1. Resolve the PR.

   • If the user gives a PR URL/number, use it.
   • Otherwise use the current branch with gh pr view --json number,url,headRefName,headRefOid.
   • Record repo_full_name, PR number, current head SHA, branch name, and review bot name if known.

2. Discover tools.

   • Prefer GitHub MCP tools for PR reads/writes when available.
   • Use gh for thread-aware reads, Actions status, and fallback writes.
   • Search for reviewer-specific MCP tools only when the user names one, e.g. Greptile or Griptile. Use that MCP for re-review if exposed.
   • If no reviewer-specific MCP exists, use the bot's documented trigger. For Greptile, a PR comment containing @greptileai forces a review; a Re-trigger Greptile URL in the bot summary can also be tried, but verify it actually starts a new check.

3. Read current state.

   • Fetch PR comments, reviews, review threads, and check runs.
   • For GitHub review threads, prefer GraphQL because flat comments do not preserve isResolved and isOutdated.
   • Treat old bot summaries as stale unless they explicitly reference the current head SHA or a check/review completed after the current head was pushed.

Useful reads:

gh pr view <PR> --repo <OWNER/REPO> --json number,url,headRefName,headRefOid,statusCheckRollup,comments,latestReviews,reviewDecision,mergeStateStatus
gh api graphql -f owner='<OWNER>' -f name='<REPO>' -F number=<PR> -f query='query($owner:String!, $name:String!, $number:Int!) { repository(owner:$owner, name:$name) { pullRequest(number:$number) { headRefOid comments(last:20){nodes{author{login} body createdAt updatedAt url}} reviews(last:20){nodes{author{login} state body submittedAt commit{oid} url}} reviewThreads(first:100){nodes{isResolved isOutdated path line comments(first:20){nodes{databaseId author{login} body createdAt updatedAt url outdated path line}}}} } } }'

Review Loop

Repeat this loop until the exit criteria are met.

1. Wait for the bot when needed.

   • If the bot check is queued or IN_PROGRESS, poll every 45-120 seconds.
   • Do not act on stale findings while a newer bot run is active.
   • Keep brief progress updates during long waits.

2. Classify feedback.

   • Actionable: correctness bugs, runtime risks, data-loss risks, API misuse, unresolved review threads, or bot summary items that say the PR is not ready.
   • Usually non-blocking: minor style suggestions, performance notes at unlikely scale, redundant-but-correct code, or informational comments when the bot still gives 5/5/no blockers.
   • If a bot gives 5/5 and says safe to merge, stop even if it mentions minor non-blocking observations.

3. Implement actionable fixes.

   • Keep changes scoped to the feedback.
   • Do not edit generated files when repo instructions say to edit sources and regenerate.
   • Preserve user changes in the worktree. Never reset or revert unrelated changes.
   • If feedback conflicts or would create a behavioral regression, pause and report the tradeoff instead of guessing.

4. Verify.

   • Run focused tests or checks covering the fix.
   • Run broader checks when the change touches shared behavior.
   • If a repo has app hot-reload instructions, follow them after edits unless there is a concrete reason reload is impossible or unnecessary. State the exact reason when skipped.

5. Commit and push.

   • Commit only the files for the review fix.
   • Use a short message tied to the feedback.
   • Push the PR branch.

6. Trigger re-review.

   • Prefer the named reviewer MCP if available.
   • Otherwise trigger through the reviewer mechanism. For Greptile, post a short PR comment such as:

Addressed the current Greptile review feedback in <commit-sha>.

@greptileai

• Confirm a new review/check starts for the new head. A successful HTTP response or reaction is not enough.

7. Poll completion and re-read.
   • Wait for the bot check/review to complete.
   • Re-fetch comments, review threads, and check status.
   • Confirm the latest bot result references the current head commit or completed after the head was pushed.

Exit Criteria

Stop when all are true:

• The latest review bot result applies to the current head SHA.
• The bot check is successful or the bot summary says safe/green.
• The bot reports confidence 5/5, or there are no actionable unresolved comments to address.
• Thread-aware reads show no unresolved actionable bot review threads. Old threads may remain if they are resolved or outdated.
• The local branch is clean and pushed to the PR branch.

Report the final state with:

• PR URL and head commit.
• Review bot result, e.g. Greptile 5/5.
• Commits pushed.
• Verification commands and outcomes.
• Any skipped required step with exact reason, especially hot reload or unavailable reviewer MCP.

Guardrails

• Do not sleep forever. If the same pending state repeats for several polls and there is no evidence the bot is making progress, report the blockage and the last observed state.
• Do not treat a GitHub Actions failure as reviewer feedback unless it blocks the requested green state or the user asked to fix CI. Still mention failing checks that remain.
• Do not mark GitHub threads resolved unless the user explicitly asked for that write action. Bot reruns often resolve or obsolete threads automatically.
• Do not rely only on a top-level PR comment summary when review threads exist; always do at least one thread-aware read before declaring green.