Babysit PR

babysit-pr

Purpose

After a push or PR creation, CI checks and automated reviewers (CodeRabbit, GitHub Actions) produce status checks and review comments. This skill monitors those results, analyzes review comments and check failures, fixes legitimate issues, pushes, and loops - up to 3 rounds.

State file

/tmp/codex-babysit-pr-state.json tracks progress across monitoring cycles:

{
  "pr_number": 123,
  "round": 0,
  "max_rounds": 3,
  "processed_comment_ids": [],
  "started_at": "2026-06-08T10:00:00Z"
}

• round increments each time you push a fix. Checking status without pushing does NOT count as a round.
• Lock file: /tmp/codex-babysit-pr.lock — prevents the PostToolUse hook from re-triggering while this skill is active.

Workflow

Step 0 — Initialize or resume

touch /tmp/codex-babysit-pr.lock

Check if state file exists:

• No state file: Create one. Get PR number via gh pr view --json number --jq .number. Set round=0, started_at=now, processed_comment_ids=[].
• State file exists: Read it. If round >= max_rounds → go to Cleanup (max rounds). If started_at is more than 90 minutes ago → go to Cleanup (timeout).

If no PR exists for the current branch, output "No PR found for current branch" and clean up.

Step 1 — Check CI status

gh pr checks --json name,state,conclusion,link 2>/dev/null

Also fetch the overall PR status:

gh pr view --json statusCheckRollup --jq '.statusCheckRollup[] | {context: .context, state: .state, description: .description, targetUrl: .targetUrl}'

Classify:

• Some checks still PENDING -> keep the current Codex turn active, wait with the available command/session wait mechanism, and check again without incrementing the round
• Some checks FAILED → proceed to Step 2
• All checks passed → proceed to Step 2 anyway to collect review comments. Only go to Cleanup (success) if Step 2b also finds zero unprocessed actionable comments. Never short-circuit before checking comments — bots like CodeRabbit post asynchronously and may finish after CI passes.

Step 2 — Gather failures and review comments

2a — Failed checks

From the checks output in Step 1, collect all checks with conclusion == "failure" or state == "FAILURE". For each failed check:

• Note the check name, failure link/URL
• If the failure link points to a GitHub Actions run, fetch the log:

  gh run view <run_id> --log-failed 2>/dev/null | tail -100

2b — Review comments from bots

GitHub bots post comments in three different locations. You must check all three to avoid missing feedback. Bot usernames always end with [bot] — use contains matching, never exact equality.

BOT_FILTER='select(.user.login | test("coderabbitai|github-actions|codecov"))'

# 1. Inline review comments (attached to specific diff lines)
gh api repos/UniClipboard/UniClipboard/pulls/<PR_NUMBER>/comments \
  --jq "[.[] | ${BOT_FILTER} | {id, user: .user.login, body, path, line, diff_hunk, created_at}]"

# 2. Review bodies (the top-level text of a review submission)
gh api repos/UniClipboard/UniClipboard/pulls/<PR_NUMBER>/reviews \
  --jq "[.[] | ${BOT_FILTER} | {id, user: .user.login, body, state}]"

# 3. Issue comments (general PR comments — where CodeRabbit posts its
#    walkthrough summary; also used by codecov, react-doctor, vercel, etc.)
gh api repos/UniClipboard/UniClipboard/issues/<PR_NUMBER>/comments \
  --jq "[.[] | ${BOT_FILTER} | {id, user: .user.login, body: (.body | .[0:2000]), created_at}]"

Filter out IDs already in processed_comment_ids.

Why all three? CodeRabbit posts its walkthrough + actionable findings as an issue comment, not a review comment. If you only check pulls/comments and pulls/reviews, you will miss it entirely. The [bot] suffix on usernames is added by GitHub for app-installed bots — filtering on the bare name (e.g. "coderabbitai") silently drops every match.

Step 3 — Analyze and fix

For each issue (failed check or new review comment):

1. Understand the problem: Read the relevant file(s) and context.
2. Evaluate legitimacy:
   • CI check failures: always legitimate — must fix.
   • CodeRabbit comments: evaluate whether the suggestion improves correctness, security, or performance. Skip pure style nits, subjective preferences, and false positives. When skipping, note the reason briefly.
   • GitHub Actions bot comments: usually legitimate (lint errors, type errors, test failures) — fix them.
3. Fix: Edit the relevant files. Be surgical — only change what's needed.
4. Record: Add the comment/check ID to processed_comment_ids.

If the fix touches Rust code, run a quick validation:

cargo check -p <affected_crate> 2>&1 | tail -20

If the fix touches TypeScript/frontend code:

pnpm type-check 2>&1 | tail -20

Step 4 — Commit and push

Only if fixes were made:

git add <specific fixed files>
git commit -m "$(cat <<'EOF'
fix: address CI/review feedback (babysit-pr round N)
EOF
)"
git push

Replace N with the actual round number. Increment round in the state file.

If no fixes were needed (all comments were false positives / already processed, but checks are still failing for unknown reasons):

• Do NOT push an empty commit.
• Log the situation and perform one more bounded check in the same turn. If it also shows nothing fixable, stop and report to the user.