Babysit

---
name: babysit
description: >-
  Keep a GitHub PR merge-ready: triage review comments, resolve inline threads,
  wait for draft-stage Gemini feedback, promote the PR when ready, verify the
  Copilot review pass, fix merge conflicts when intent is clear, and repair
  merge-blocking CI with small scoped commits until checks are green.
  Tool-agnostic — use in Cursor, Claude Code, Codex, Copilot, or any agent
  that can run git and gh.
---
<!-- GENERATED SKILL MIRROR: do not edit directly -->

# babysit

## Mandatory first output

Before doing anything else, print:

```text
[babysit] Skill active. Working PR merge-readiness...

When to use

• User says babysit, babysit PR, /babysit, or /babysit 154 (PR number).
• Review agent or operator wants the branch green, threads resolved, and no trivial blockers before merge.
• Team workflow uses a draft PR -> Gemini review -> ready for review -> Copilot review relay and wants that sequence handled with minimal manual prompting.

HARD CONSTRAINT — small, scoped fixes only: Only small, scoped fixes for CI, merge hygiene, or obvious comment-driven nits. No feature work or contract changes unless the user explicitly widens scope.

HARD CONSTRAINT — do not merge: Do not merge the PR unless the user explicitly asks you to merge; babysit stops at merge-ready.

HARD CONSTRAINT — stop on judgment calls: If a conflict or comment requires product or architecture judgment, stop and ask instead of guessing.

HARD CONSTRAINT — bounded waiting only: Poll for bot activity on a bounded loop (for example, every 30 seconds for up to 15 minutes) and then report what is still missing. Do not wait forever.

Inputs

1. PR number — from the user message (e.g. 154). If missing, ask: Which PR number should I babysit?
2. Repo — current working tree should be this repository (risk-manager), with origin pointing at GitHub.

Prerequisites

• gh CLI authenticated (gh auth status).
• git with fetch access to origin.
• GitHub API access via gh api for reviews, comments, requested reviewers, and GraphQL thread resolution.

Procedure (loop until stable or blocked)

1. Snapshot PR state

gh pr view {pr_number} --json title,state,isDraft,url,mergeable,mergeStateStatus,baseRefName,headRefName,reviewDecision
gh pr checks {pr_number}

Report: mergeable, merge-state (e.g. blocked by rules), and which checks passed / failed / pending.

If checks are still running, wait and re-run gh pr checks before declaring done.

Capture {owner} and {repo} once from origin or gh repo view --json name,owner.

2. Checkout PR head (before any local commits)

gh pr checkout {pr_number}

Confirm your branch matches the PR head (headRefName from step 1). If you only read state and make no commits, checkout is optional; once you edit or commit, you must be on the PR head branch.

3. Branch freshness and conflicts

git fetch origin

Use baseRefName from step 1 (often main, not always). Compare the PR head to origin/<baseRefName>.

• If the PR branch is behind origin/<baseRefName> and CI or review expect an updated base, merge or rebase per repo convention (prefer merge from base into PR branch if unsure, to avoid force-push surprises).
• If merge conflicts exist, open conflicted files. Resolve only when the correct resolution is obvious from both sides; otherwise stop with a short conflict summary for the human.

4. Bot review inventory helpers

Use these endpoints repeatedly during the babysit loop:

gh api repos/{owner}/{repo}/pulls/{pr_number}/reviews
gh api repos/{owner}/{repo}/issues/{pr_number}/comments
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments
gh api repos/{owner}/{repo}/pulls/{pr_number}/requested_reviewers

Use a GraphQL thread query when you need thread ids and resolution state:

gh api graphql -f query='query($owner:String!, $repo:String!, $pr:Int!) { repository(owner: $owner, name: $repo) { pullRequest(number: $pr) { reviewThreads(first: 100) { nodes { id isResolved comments(first: 20) { nodes { author { login } body url createdAt } } } } } } }' -F owner={owner} -F repo={repo} -F pr={pr_number}

Use the exact bot identities and structures already observed in this repository:

• Gemini review login via REST: reviews[].user.login == "gemini-code-assist[bot]" with a body starting ## Code Review
• Gemini inline thread login via GraphQL: reviewThreads.nodes[].comments.nodes[].author.login == "gemini-code-assist" with severity badges and often a suggestion block
• Gemini fallback issue-comment shape: issues/{pr_number}/comments[].user.login == "gemini-code-assist[bot]" with a note that Gemini could not generate a review for the file types involved
• Copilot review login via REST: reviews[].user.login == "copilot-pull-request-reviewer[bot]" with a body starting ## Pull request overview
• Copilot inline thread login via GraphQL: reviewThreads.nodes[].comments.nodes[].author.login == "copilot-pull-request-reviewer" with focused file-level comments and occasional suggestion blocks
• Copilot requested-reviewer shape via REST: requested_reviewers.users[].login commonly includes Copilot

Treat these observed shapes as the default arrival signals:

• Gemini arrived when reviews or issue comments use user.login == "gemini-code-assist[bot]", or review threads use author.login == "gemini-code-assist".
• Copilot arrived when reviews use user.login == "copilot-pull-request-reviewer[bot]", review threads use author.login == "copilot-pull-request-reviewer", or requested_reviewers.users[].login includes Copilot.

If the PR already has Gemini or Copilot activity when babysit starts, treat that as the relevant review having already arrived; do not wait for a second copy before triaging.

5. Draft-stag