babysit-pr

Files (1)

• SKILL.md

SKILL.md (first lines)

# Babysit PR

Drive an open pull request to a merge-ready state. This may run for hours — work
autonomously in a loop until done or blocked.

## Invocation

Examples:

- `/babysit-pr on #1034`
- `Babysit PR #1034 until merge-ready`
- `Babysit this PR` (resolve from current branch)
- `/babysit-pr --merge #124 #125 #126` (shepherd **and** merge, in queue order)

One babysitter for many PRs beats one babysitter per PR — they share a single
CodeRabbit rate limit, so a single session drains the queue without multiplying
review-limit stalls.

## Hard rules

1. **Never approve** the PR. **Never merge unless invoked with `--merge`** — the flag
   is the explicit authorization to merge; without it, only the human owner merges.
2. **Lint before every commit** — read and follow the `lint` skill (`uv run lintro fmt`
   then `uv run lintro chk`, zero issues). Do not use `--tools` filtering.
3. **Never push while CI is pending or running** on the PR head.
4. **Minimal diffs** — fix only what the PR scope and valid review/CI feedback require.
5. **Never weaken CI/workflows** just to make checks pass; report instead if that seems
   necessary.
6. **Never force-push**, amend pushed commits, or rewrite history unless the user
   explicitly requested it.

## Composed skills

- **`lint`** — pre-commit formatting and checks (required gate).
- **`commit`** — conventional commits, signed commits, semantic prefixes.
- **`gh-fix-ci`** (if available) — inspect failing GitHub Actions checks and logs.

Do not duplicate their full workflows here — read and follow them at commit time.

## Phase 0 — Resolve target PR

1. **PR number**: Extract from the user message (`#123`, URL) or resolve from the
   current branch:

   ```bash
   gh pr view --json number,url,title,headRefName,baseRefName,state,mergeable,mergeStateStatus
   ```

2. **Repository**: Use `gh repo view --json nameWithOwner` from the worktree, or parse
   from a PR URL.

3. **Worktree**: Prefer a path from conversation context. Otherwise scan worktrees:

   ```bash
   git worktree list
   ```

   Match `headRefName` to a worktree path. If none exists, use the current git root
   only when it matches the resolved PR branch. Otherwise stop and ask for the
   correct worktree before continuing.

4. **Load repo context** (after the target worktree is known): From that worktree
   root only, read `AGENTS.md` and/or `CLAUDE.md` if present. **Do not** read
   context from the parent checkout or any other repo. **Precedence:**
   `AGENTS.md` is authoritative when both exist — do not also apply conflicting
   `CLAUDE.md` instructions; if only one exists, use that file; if both conflict
   in a blocking way, stop and ask. Treat house standards, operating agreement
   (including merge policy / merge-queue notes), and standing constraints as
   **binding** for this babysit run. See the `stand-general` skill's **Per-repo
   agent context** section for the expected file shape. Missing the file is fine
   — fall back to chat instructions and this skill's defaults.

5. **Snapshot** before looping: PR URL, branch, worktree path, latest commit SHA,
   check summary, open review threads.

## Phase 1 — Launch background sub-agent (if supported)

Babysitting is long-running. After Phase 0, if the agent supports background sub-agents
(e.g. Claude Code's general-purpose agent run in the background), launch one and pass it
the resolved PR metadata, worktree path, hard rules, and this skill's main loop (Phase 2
onward). In that mode, the parent agent returns immediately with the sub-agent link and
handoff snapshot. The sub-agent runs until exit conditions are met or a human blocker is
found.

**Portability note:** on agents without background sub-agents, skip the handoff,
tell the user the babysitting loop will occupy the current session, and run the
main loop (Phase 2 onward) inline instead.

## Phase 2 — Main loop

Repeat until exit conditions (Phase 5) or a blocker. Track loop iterations and elapsed
time; **stop and report** if more than 20 iterations or 6 hours pass without reaching
exit conditions (avoids unbounded token/API cost on flaky CI or re-triggering bots).

### Step A — Wait for CI

```bash
gh pr checks <number> --repo <owner/repo>
```

If any check is `pending` or `in_progress`, wait and re-poll. **Re-poll every 60
seconds; after five consecutive pending polls, double the interval up to 5 minutes.**
**Do not push** during this window.

### Step B — Merge conflicts

If `mergeable` is `CONFLICTING`, resolve intelligently in the worktree preserving branch
intent. If intents conflict, stop and report — do not guess.

If the branch is behind base and failures look unrelated, merge onto latest base per
repo convention. Only rebase/cherry-pick if the user explicitly approves rewriting
history.

### Step C — Fix CI failures

For each failing GitHub Actions check:

1. Get check status via `gh pr checks --json`; fetch logs separately with
   `gh run view <run_id> --log`.

From lgtm-hq/ai-skills, MIT.

More from lgtm-hq/ai-skills