name	description
babysit-pr	Monitors a pull request until it is ready to merge. Checks CI status, reviews PR comments, and automatically fixes issues. Use when someone says "babysit this PR", "watch this PR", "monitor PR", "fix PR issues", or "get this PR ready to merge".

Babysit PR

Continuously monitors a pull request, identifies failures or requested changes, fixes them, and pushes updates until the PR is green and review-clean.

Usage

/babysit-pr [PR number or URL]

If no PR number is provided, detect it from the current branch.

Workflow

Run this loop until the PR is ready to merge (all checks pass, no unresolved comments):

Step 1: Identify the PR

# If PR number provided, use it directly
# Otherwise, detect from current branch:
gh pr view --json number,url,headRefName,state

Step 2: Check PR Status

Gather all status signals in parallel:

# CI check status
gh pr checks <PR_NUMBER>

# Unresolved review comments
gh api repos/{owner}/{repo}/pulls/<PR_NUMBER>/comments --jq '.[].body'

# Review status (approved, changes requested, etc.)
gh pr view <PR_NUMBER> --json reviews,reviewDecision

# PR merge status
gh pr view <PR_NUMBER> --json mergeStateStatus,mergeable

Step 3: Triage Issues

Categorize what needs attention, in priority order:

1. CI Failures — Tests, lint, build, or type-check failures
2. Review Comments — Unresolved reviewer feedback
3. Merge Conflicts — Branch is out of date or has conflicts

Step 4: Fix CI Failures

For each failing check:

# Get the failed job logs
gh run view <RUN_ID> --log-failed

Then:

• Test failures: Read the failing test, understand the error, fix the code or test
• Lint failures: Run the linter locally, apply fixes
• Build failures: Read the error, fix the source
• Type errors: Fix type issues in the flagged files

After fixing, commit and push:

git add <files>
git commit -m "fix: <describe what was fixed>"
git push

Step 5: Address Review Comments

For each unresolved comment:

1. Read the comment and understand the request
2. Check if it's actionable code feedback (vs. a question or acknowledgment)
3. If actionable: make the requested change, commit, and push
4. If unclear: summarize what you found and ask the user for guidance

Step 6: Handle Merge Conflicts

# Check if branch is behind
gh pr view <PR_NUMBER> --json mergeStateStatus

# If behind, rebase
git fetch origin main
git rebase origin/main
git push --force-with-lease

IMPORTANT: Only rebase if there are actual conflicts. Do not force-push unnecessarily.

Step 7: Verify and Report

After pushing fixes, wait for CI to start, then check status again.

Report a summary to the user:

PR #<number> Status:
- CI: [passing/failing] (X/Y checks passed)
- Comments: [X unresolved]
- Merge: [ready/blocked]
- Action taken: <what was fixed>

Step 8: Loop or Complete

• If all checks pass and no unresolved comments: Done — report that the PR is ready to merge
• If issues remain: go back to Step 2
• If stuck on something that requires user input: stop and explain what needs manual attention
• Max iterations: 5. If not resolved after 5 rounds, stop and report remaining issues

Rules

• Never force-push to main/master
• Never skip pre-commit hooks (no --no-verify)
• Create new commits for fixes (don't amend unless the user asks)
• Don't auto-merge — just report when the PR is ready. The user decides when to merge
• Don't dismiss reviews — only address the feedback
• If a CI failure is clearly pre-existing (fails on main too), note it and move on
• If a review comment is subjective or architectural, flag it for the user instead of making changes
• Respect the project's CLAUDE.md rules (test requirements, code style, etc.)

Detecting the PR

Priority order for finding which PR to babysit:

1. Explicit argument: /babysit-pr 806
2. Explicit URL: /babysit-pr https://github.com/owner/repo/pull/806
3. Current branch: gh pr view --json number (uses the PR associated with HEAD)