kevinslin/babysit-pr

PR Babysit Loop

Use this skill when the user asks to babysit, watch, or keep an eye on a pull request until review comments and CI are settled.

Setup

1. Identify the PR URL or number. If the user did not provide one, infer it from the current branch with gh pr view when possible; otherwise ask for the PR.
2. Confirm gh is available and authenticated for the PR repo.
3. Create one dedicated thread automation for the loop. Name it with the repo and PR number, for example babysit-pr: owner/repo#123.
4. Store loop state in the automation context: PR identifier, last seen issue/comment/review identifiers, current head SHA, and the start time of the current quiet-green window. Do not create repo files just to track loop state.

If the runtime has no first-class thread automation API, emulate the loop in the current agent thread with timed sleeps and state that no persistent automation API was available.

Polling Loop

Poll every 2 minutes until the heartbeat pass condition, explicit quiet-green pass condition, or a terminal stop condition is reached.

At each poll:

1. Poll GitHub for new PR activity since the last baseline:
   • Issue comments and reviews from gh pr view <pr> --json comments,reviews,reviewDecision,mergeStateStatus,mergeable,baseRefName,headRefName,headRefOid.
   • Inline review threads through GraphQL pullRequest.reviewThreads, including unresolved, non-outdated threads and requested changes.
   • When starting on an existing PR, do not ignore older unresolved bot or reviewer comments just because they predate the loop. Re-evaluate comments with concrete file/line findings against the current head; if the finding still applies, treat it as actionable. If it is fixed by the current head, record it as superseded and continue.
   • After every new pushed head, re-check prior actionable comments before starting or continuing the quiet-green window. A green CI run is not enough when an older concrete review finding still applies.
   • Branch merge conflicts: treat mergeStateStatus of DIRTY or mergeable of CONFLICTING as a PR branch conflict.
   • Other blocked merge states.
2. Poll CI for the current head SHA:
   • Start with gh pr checks <pr> or gh pr view <pr> --json statusCheckRollup.
   • Treat GitHub check data as time-series data, not one row per check name. For the current headRefOid, group runs by stable check identity: prefer workflowName + name when both exist, otherwise use the provider check name plus provider/source as the identity.
   • For each check identity, classify only the latest run by startedAt/completedAt/provider timestamp. Older failed, errored, cancelled, neutral, or pending runs for the same check identity are superseded once a newer run exists for the same PR head.
   • When repeated check names disagree, use the latest run as the current state and include the older run only as history in the evidence summary. This covers reruns caused by new commits, manual reruns, and PR-metadata edits such as body, label, or title updates.
   • Use repo-specific CI links or provider CLIs when the PR exposes them.
   • Use trigger:check-ci from ../dev.shortcuts/SKILL.md when checks need deeper Buildkite/provider classification.
   • For failed, errored, cancelled, or clearly stuck rollup checks, inspect the leaf check/job log before classifying relatedness. Prefer the check details URL or job id; use gh run view <run-id> --job <job-id> --log or the provider CI equivalent when available. If gh cannot write to its default cache location, set XDG_CACHE_HOME to a writable temp directory for the log fetch. Treat rollup status names as pointers, not evidence.
3. Classify issues:
   • New actionable comments, requested changes, unresolved review threads, or older still-applicable concrete findings are GitHub issues.
   • PR branch conflicts are conflict issues.
   • Failed, errored, cancelled, or clearly stuck latest checks are build issues only after leaf log evidence shows a concrete failure. If the latest leaf job is still running or logs are unavailable because CI has not produced them yet, keep the check pending/running and continue polling.
   • Pending/running latest checks are not build issues, but they prevent the heartbeat CI-green stop condition from passing.
   • Superseded older check failures do not block the quiet-green window unless the current latest run for the same check identity is also failing, missing, or stale.

Fix Cycle

When any conflict issue is found:

1. Capture a short evidence summary: PR, head SHA, base branch, head branch, mergeStateStatus, mergeable, and any GitHub merge-conflict URL.
2. Invoke trigger:fix-pr-conflict from ../dev.shortcuts/SKILL.md with the PR and conflict evidence.
3. After the conflict fix flow completes, refresh the PR head SHA and reset the quiet-green timer.
4. If the conflict repair dropped or skipped any commit, scan the PR title/body against the current diff before restarting CI polling. Remove or update stale claims for changes no longer present on the PR branch.
5. Return to the 2-minute polling loop.

When any GitHub or build issue is found:

1. Capture a short evidence summary: PR, head SHA, comment/review/check identifiers, URLs, failure names, and leaf job log excerpts or failing file/test names when available.
2. Invoke trigger:fix-pr from ../dev.shortcuts/SKILL.md with the PR and evidence. Do not hand-roll PR comment cleanup inside this skill; trigger:fix-pr owns addressing feedback, committing/pushing when needed, resolving addressed review threads, and checking CI.
3. After the fix flow completes, re-query pullRequest.reviewThreads through GraphQL and verify that every addressed thread has isResolved: true. If any actionable or addressed-but-unresolved thread remains, treat that as a GitHub issue and invoke trigger:fix-pr again with the remaining thread ids/URLs as evidence.
4. Refresh the PR head SHA and reset the quiet-green timer.
5. Return to the 2-minute polling loop.

Do not mark the babysit loop complete immediately after a fix unless the fresh post-fix poll already satisfies the heartbeat CI-green stop condition. A quiet-green window is required only when the user explicitly asked to keep watching after green.

Pass Condition

For heartbeat automations, complete and delete the heartbeat as soon as all of these are true:

1. CI is green for the current head SHA.
2. No new actionable GitHub issues have appeared.
3. There are no unresolved actionable review threads, requested changes, branch conflicts, or current-head build failures requiring a fix.

Do not keep a heartbeat automation alive only for a quiet-green window, codeowner/compliance approval gates, skipped bot-approval triggers, or a blocked merge state that is explained solely by approvals. Delete the heartbeat, notify/report the green CI result, and mention any remaining non-actionable approval gate separately.

If the user explicitly asks to keep watching after green, use a quiet-green pass condition instead: the PR must stay in the CI-green/no-new-actionable-issues state for at least 10 continuous minutes, checked at the 2-minute cadence. Reset that timer whenever a new commit appears, CI stops being green, or new actionable GitHub activity appears.

Completion And Cleanup

When the heartbeat CI-green pass condition or explicit quiet-green pass condition is met:

1. Delete or cancel the thread automation that was running the babysit loop.
2. Use ../gen-notifier/SKILL.md to send exactly one completion notification.
3. Report the PR, final head SHA, checks status, automation deletion status, and any remaining non-actionable approval/compliance gate. Include quiet-window duration only when the user explicitly requested a quiet-green watch.

If the loop hits an unrecoverable error, delete or cancel the automation when possible, notify with an error status through ../gen-notifier/SKILL.md, and report the blocker.