/babysit-pr — Autonomous PR shepherding

One tick of work against a single PR: sync, fix what's red, address review feedback, push, and queue auto-merge. Designed to run under /loop 5m /babysit-pr <PR> so the same tick fires every 5 minutes until the PR lands. Inspired by Boris Cherny's /loop 5m /babysit workflow.

The skill is stack-agnostic. It detects what kind of repo it's in (Cargo workspace vs pnpm+uv monorepo, etc.) and derives fix commands from that — then classifies each failing CI job by name pattern, not a hardcoded table, so new or renamed jobs in the pipeline don't require skill edits.

When to use

• User ran /loop 5m /babysit-pr <PR> and a tick just fired.
• User directly invoked /babysit-pr <PR-number-or-url>.
• User described wanting a PR "driven to merge" / "nursed along" / "watched until green".

When NOT to use

• To open a new PR — that's /go. This skill assumes the PR already exists.
• For a pre-push local check — run the project's verify workflow separately; /go already wraps one.
• To merge someone else's PR you can't review — the skill respects CODEOWNERS; if a required reviewer hasn't approved, auto-merge queues but never fires.

Arguments

/babysit-pr <pr-number-or-url>

Examples: /babysit-pr 123, /babysit-pr https://github.com/<owner>/<repo>/pull/123. If no arg: stop with "missing PR arg — usage: /babysit-pr <PR#>".

One tick

A tick should complete in ≤ 2 minutes. /loop 5m polls at 5-minute intervals, so a short tick leaves headroom and guarantees that the next tick always sees fresh CI state. Keep ticks idempotent: re-running against the same PR state produces the same outcome.

Budget caps per tick (override only with explicit justification):

If a tick hits a cap, the next tick picks up where this one stopped. Better to ship a partial improvement every 5 minutes than burn 15 minutes on one mega-tick.

Phase 0 — Pre-flight (with stack detection)

REPO_ROOT=$(git rev-parse --show-toplevel)
cd "$REPO_ROOT"

# Stack detection — same shapes /go knows
STACK=unknown
[ -f "Cargo.toml" ] && STACK=rust-cargo
if [ -d "webapp" ] && ls services/*/pyproject.toml >/dev/null 2>&1; then
  STACK=pnpm-uv-monorepo
fi
[ "$STACK" = "unknown" ] && [ -f "pyproject.toml" ] && [ -f "package.json" ] && STACK=pnpm-uv-monorepo

# Parse PR arg — bare number, #123, or full URL
PR_ARG="$1"
OWNER_REPO=$(gh repo view --json nameWithOwner -q .nameWithOwner)
PR_NUM=<extracted from arg>

# gh auth — hard stop if unauthenticated
gh auth status >/dev/null 2>&1 || { echo "gh not authenticated — run: gh auth login"; exit 2; }

# Single metadata fetch
gh pr view "$PR_NUM" \
  --json state,isDraft,headRefName,baseRefName,mergeStateStatus,statusCheckRollup,reviews,author,url,title \
  > /tmp/babysit-pr-$PR_NUM.json

Decision table on initial state:

If STACK=unknown, Phase 2 falls back to rerun-or-escalate only — the skill still shepherds reviews and auto-merge, but won't guess at build commands for a repo it doesn't recognize.

State file: $REPO_ROOT/.local/state/babysit-pr-<pr>.json — per-repo, scoped under the active checkout's .local/state/ (where $REPO_ROOT is what Phase 0 captured via git rev-parse --show-toplevel). Create the directory if missing. .local/ is chosen over .claude/state/ because writes under .claude/ trigger Claude Code's sensitive-path validation prompt every tick, which defeats the unattended-loop property; .local/ is unprivileged scratch and writes through silently. On first write, append .local/ to the repo's .gitignore if no existing entry already covers it — per-PR tick state is local-only scratch and must never land in a commit. If the user invoked the skill from a linked worktree (rare), $REPO_ROOT resolves to that worktree's path, which is still correct: state stays alongside the checkout the user is actually driving from. Shape:

{
  "pr": "<owner>/<repo>#<number>",
  "processed_comment_ids": [101, 102, 103],
  "failed_fix_attempts": { "<job-name>": 1 },
  "last_tick": {
    "at": "2026-04-24T19:25:00Z",
    "commits_pushed": 1,
    "checks_failing": ["<job-name>"],
    "merge_queued": true,
    "summary": "…"
  }
}

processed_comment_ids prevents replying to the same reviewer comment twice. failed_fix_attempts tracks per-job retry count — if the same job has failed 3 consecutive ticks with 3 different fix attempts, stop attempting that job. Auto-merge stays queued; the human gets notified via the tick summary.

Phase 1 — Checkout sync (worktree)

The user is almost certainly working on something else in their main checkout. Use a dedicated worktree so the tick doesn't clobber their current branch:

WT="$HOME/.claude/worktrees/babysit-$OWNER-$REPO-$PR_NUM"
HEAD_REF=<from metadata>
BASE_REF=<from metadata>

if [ ! -d "$WT" ]; then
  git worktree add "$WT" "origin/$HEAD_REF" 2>/dev/null \
    || git worktree add -b "$HEAD_REF" "$WT" "origin/$HEAD_REF"
fi
cd "$WT"
git fetch origin "$HEAD_REF" "$BASE_REF"
git reset --hard "origin/$HEAD_REF"   # re-align if someone force-pushed

Rebase on base (only if mergeStateStatus == "BEHIND"):

Try a clean rebase first. If it lands without conflicts, push with --force-with-lease (never --force) so a concurrent push from the user wins over ours and we move on:

if git rebase "origin/$BASE_REF"; then
  git push --force-with-lease origin "$HEAD_REF"
else
  # Conflicts. Enter the autonomous resolver. See "Autonomous conflict resolution" below.
  if resolve_rebase_conflicts_and_test ; then
    git push --force-with-lease origin "$HEAD_REF"
  else
    # Resolver gave up — back out cleanly and let a human take it.
    git rebase --abort 2>/dev/null
    git reset --hard "origin/$HEAD_REF"
    NEEDS_MANUAL_REBASE=1
  fi
fi

--force-with-lease is the only acceptable force here. A bare --force overwrites concurrent work the user may have pushed; the lease compares against the remote tip we just fetched and refuses if anything changed underneath us, which is exactly the property we want from an unattended loop.

#### Autonomous conflict resolution

A rebase can pause on any commit being replayed, not just the first. After every conflict, classify each conflicted file by path/content and resolve it; when the step is clean, git rebase --continue advances to the next replay. Loop until the rebase is fully applied or a cap trips.

Per-step flow (repeat for every paused step in the rebase):

1. git diff --name-only --diff-filter=U — list files with unresolved conflicts.
2. For each conflicted file, classify by the first matching tier:

1. After every conflict in the step is staged, run a fast syntactic sanity check appropriate to the stack — cargo check --workspace (rust), pnpm tsc --noEmit plus uv run python -m compileall -q services (pnpm-uv). If it fails the resolution is structurally broken — abort the rebase and escalate.
2. If sanity passes: git rebase --continue. If --continue reports new conflicts (the next replayed commit), loop to step 1.

Caps inside the resolution loop — past any of these, give up cleanly rather than dig deeper:

• >20 file-resolutions across the entire rebase — the divergence is structural, not mechanical.
• >15 minutes wall-clock — this phase is allowed to exceed the normal 2-minute tick budget because rebasing is genuinely slower, but not arbitrarily so.
• Same file conflicts in ≥3 replay steps of the same rebase — both sides have churned the same region; resolutions compound and the AI is no longer choosing, it's guessing.

On a cap trip: git rebase --abort, git reset --hard origin/$HEAD_REF, write the reason into the tick summary, escalate.

Post-rebase test gate (mandatory when any code-tier file was resolved by AI):

A green compile is not a green test suite. AI-resolved code can build and still be semantically wrong — picking the wrong side, dropping a guard, merging two branches' edits into a logically inconsistent state. The test suite is the only mechanical signal that catches "I chose the wrong side," and skipping it converts this whole phase from "assisted rebase" back to "coin flip."

case "$STACK" in
  rust-cargo)        cargo test --all-features --workspace ;;
  pnpm-uv-monorepo)  pnpm -r test && (cd services && uv run pytest) ;;
  *)                 echo "stack=$STACK has no configured test command — escalating"; return 1 ;;
esac

• Green → return success; the outer flow pushes with --force-with-lease.
• Red → git reset --hard origin/$HEAD_REF to undo every resolved commit, return failure so the outer flow sets NEEDS_MANUAL_REBASE=1. Do NOT push a force-with-lease over red tests; the whole point of the gate is to refuse that.

If only lockfile/generated/imports-only tiers fired (no AI judgment on code), the gate is still recommended but the cost/benefit is lower — a regenerated lockfile rarely changes test outcomes. Keep it on by default; the test command's wall-clock is bounded by the project's own suite.

Forbidden during conflict resolution:

• git checkout --theirs <path> or --ours <path> blanket on directories (e.g. --theirs .) — every file must be classified individually so we don't silently drop someone's work.
• Resolving by deleting the conflicting block unless both sides clearly agreed to remove it (rare; usually means the human meant to keep one).
• Leaving a // TODO: revisit conflict or any deferred-fix marker. The resolution is final or it's not done.
• Skipping the post-rebase test gate "to save tick time." This gate is the entire reason the autonomous resolver is safe to run.

Phase 2 — Fix failing CI (pattern-match + stack-dispatch)

Parse statusCheckRollup from metadata. Each entry has name, conclusion (SUCCESS/FAILURE/CANCELLED/SKIPPED/null), and detailsUrl. For each failing required check, classify by name and execute at most one strategy per tick.

Why one strategy per tick? Each push triggers a fresh CI run. Stacking three fixes for three different jobs in one tick means the second and third fixes never got to see the first fix's CI verdict — you could be adding unnecessary or conflicting changes. Shipping one category per tick gives CI a clean signal before the next tick reads state.

#### Classification by name pattern

Compare the job name (case-insensitive) against these regexes, first-match wins:

Non-fatal / soft-fail jobs: GitHub has exactly one machine-readable signal for "this check is advisory, not blocking": conclusion == NEUTRAL. Treat NEUTRAL (and SKIPPED) as non-blocking. Treat everything else — including FAILURE on a check that branch protection happens to not list as "required" — as a real failure that must go green before the skill queues auto-merge. The "required" flag in statusCheckRollup is a branch-protection setting, not a quality signal: many repos run lint / scan / e2e jobs that aren't listed as required but are still gates the team expects to be green. Chase them like any other failure. (This is what Phase 5's gate enforces — see below.)

#### Strategy by category (commands branch on STACK)

format

• rust-cargo: cargo fmt --all. Commit: style: apply cargo fmt.
• pnpm-uv-monorepo: pnpm biome check --write . (webapp) / uv run ruff format . (services/*).
• Unknown stack: skip, don't guess.

lint

• rust-cargo: cargo clippy --fix --allow-dirty --allow-staged --all-targets --all-features; hand-fix what --fix misses (read the diagnostic, don't silence with #[allow]).
• pnpm-uv-monorepo: pnpm biome check --write . and/or pnpm lint:fix (webapp); uv run ruff check --fix . (services/*).
• Commit: style(<scope>): apply <tool> auto-fixes.

regenerate

• rust-cargo: cargo build (re-runs build.rs, regenerates src/generated/). Stage output.
• pnpm-uv-monorepo: pnpm run generate at repo root. Stage output.
• If the validate job is flagging dep/schema freshness (age-based pin, e.g. "schemas are >30 days old") rather than drift → this is JUDGMENT, not regenerate. Escalate; don't auto-bump pinned vendor schemas.
• Commit: chore(<scope>): regenerate generated code or chore(schemas): regenerate bindings.

typecheck

• Read the error output; fix types at source. Never reach for any, @ts-ignore, @ts-expect-error, # type: ignore, # noqa without a rule code, unsafe {}, or similar escape hatches.
• If the fix isn't obvious from the error + the file it names → escalate; don't guess.
• Commit: fix(<scope>): <type error description>.

test

• Fetch the failed log: gh run view <runId> --log-failed. Read the first N lines of the failure (typically 50–200 is enough to isolate).
• If the failure is in a file the PR touches AND the root cause is clear: read the test AND the code-under-test, apply the smallest fix, commit. fix(<scope>): <what the test was proving>.
• If the failure looks flaky (same code passes on main, timeout, network hiccup, port in use, DNS): gh run rerun <runId> --failed. Don't touch code.
• If ambiguous: escalate — the human decides whether it's a real bug or a flake.

migration — always escalate. Multi-head conflicts, naming collisions, linter rejections, downgrade paths: all require migration-tool judgment (Alembic, Prisma, sqlx, Diesel) that can corrupt production data if guessed wrong. Log the reason in summary, increment failed_fix_attempts, move on.

build / docker

• Fetch log. Classify the failure:
• Dep-install failure (lockfile drift, missing pkg, hash mismatch): run the project's lockfile refresh — uv sync, pnpm install, or cargo update -p <crate> for a single crate — commit the lockfile. build(deps): refresh <service> lockfile.
• Registry timeout / rate limit / network flake: gh run rerun <runId> --failed.
• Base image change, Dockerfile syntax, out-of-space, OOM: escalate. The breakage surface is too large for a mechanical fix.

container-scan / dep-scan — bump aggressively, gate by tests.

The old policy ("only direct deps, only within same major, base images escalate") leaves most CVEs to humans, which defeats the unattended-loop premise. The new policy bumps direct, transitive, and base-image targets — including across major versions when no in-major fix exists — and uses the project's own test suite as the safety net. A bump that breaks the suite is reverted, never forced through.

Read the scan output (job log via gh run view <runId> --log-failed, or the SARIF/JSON the scanner uploads). For each CVE, classify by location and dispatch:

Major-bump safety check (run before attempting any major bump): intersect the PR's changed-file list with the affected package's import sites in the repo. If the PR itself touches code that imports the package being major-bumped (e.g. PR adds import express and the bump is express 4 → 5), the blast radius IS the PR's work — escalate rather than gamble. Grep is enough: git diff --name-only origin/$BASE_REF...HEAD | xargs grep -l "<pkg>".

Apply the bump, then commit the manifest + lockfile changes, then run the full local test suite:

case "$STACK" in
  rust-cargo)        cargo test --all-features --workspace ;;
  pnpm-uv-monorepo)  pnpm -r test && (cd services && uv run pytest) ;;
  *)                 echo "no test command for stack=$STACK — escalating CVE"; return 1 ;;
esac

• Green → commit. Use build(deps): bump <pkg> <old> → <new> for CVE-<id> (include the major-bump fact in the message when it crossed, e.g. bump express 4.21.1 → 5.0.0 (major) for CVE-2024-43796). Phase 4 pushes.
• Red → revert: git reset --hard HEAD~1 to drop the bump commit (or git checkout HEAD -- <lockfile> <manifest> if the bump wasn't yet committed). Increment failed_fix_attempts.<job> and escalate with a clear "tests failed after bumping X — human review" message.

Noisy scanners — if a scanner is marked continue-on-error in CI, or its output is dominated by low-severity advisories with no available fix, skip it entirely. The repo's CI config already classifies that signal as advisory; chasing it just creates churn.

coverage — most coverage failures on a single tick are transient (test flake, test ordering, upload retry). Default to one rerun. If still red and the PR genuinely dropped coverage below threshold, the fix is "write a test" — that's JUDGMENT, not a mechanical fix. Escalate.

e2e — default to one rerun (most failures are env flake: port, network, timing). If still red on a second tick, the e2e test is reading real runtime behavior — escalate.

unknown — rerun once. If it fails again on the same commit, escalate with STUCK: <job-name> in the summary.

#### PR title edit (always-on quirk)

If the PR Validate job (or any job matching pattern validate|conventional|commitlint) is red and its failure log mentions the PR title (e.g. "PR title must follow Conventional Commits"), fix via the GitHub API — the title is PR metadata, not a commit:

gh pr edit "$PR_NUM" --title "<new-title-matching-conventional-commits>"

This does not count toward the 3-commit cap and does not require a CI rerun to be triggered (the commitlint job re-reads the title).

#### Never

To sidestep a real failure:

• --no-verify, --force (always prefer --force-with-lease), disabling a test, deleting an assertion.
• (rust-cargo) #[allow(...)] without a comment explaining why, unsafe { }, unreachable!(), todo!(), panic!() in a fix path.
• (pnpm-uv) # type: ignore, # noqa without a rule code, any as a type, @ts-ignore, @ts-expect-error without an issue link.

If a suppression seems genuinely necessary, escalate with a note — the human decides, not the tick.

Phase 3 — Address reviewer comments

Skip this phase if the PR is a draft.

# File-level (inline) review comments
gh api "repos/$OWNER/$REPO/pulls/$PR_NUM/comments" --paginate > /tmp/file-comments.json
# PR-level issue comments
gh api "repos/$OWNER/$REPO/issues/$PR_NUM/comments" --paginate > /tmp/pr-comments.json

Filter out:

1. Comments whose id is in processed_comment_ids.
2. Comments whose body starts with CLAUDE: (these are replies from a previous tick of this skill — must not self-loop).
3. Comments from merge bots / CI bots (look for [bot] suffix in user.login).

For each remaining comment — blind-fix policy:

Reply via:

• gh api --method POST repos/$OWNER/$REPO/pulls/$PR_NUM/comments/$ID/replies -f body="$REPLY" for file-level comments.
• gh pr comment $PR_NUM --body "$REPLY" for PR-level comments.

After each comment, add its id to processed_comment_ids — even if no reply was sent — so the next tick doesn't re-evaluate.

Cap: 5 comments per tick. The rest wait for the next tick. This keeps the tick bounded and gives the reviewer a chance to iterate with Claude rather than get steamrolled.

CODEOWNERS are the human authority. Never dismiss or counter a maintainer review. If a CODEOWNERS reviewer rejects a change the skill just pushed, treat their next comment as canonical and revert.

Phase 4 — Push

If Phase 2 or Phase 3 produced commits:

git push origin "$HEAD_REF"
COMMITS_PUSHED_THIS_TICK=1

Exception: --force-with-lease is appropriate only after a Phase 1 rebase (which already pushed in Phase 1 — this is just a sanity case).

If `COMMITS_PUSHED_THIS_TICK=1`, skip Phase 5 entirely. A push that just landed has not yet been validated by CI — statusCheckRollup may still reflect the previous commit's checks for tens of seconds, and queueing auto-merge against stale-green checks is exactly how a PR can merge before the new commit's CI has even started. Defer the auto-merge decision to the next tick (5m later), when CI has had time to register the new HEAD and start running. Falls under the "ticks are idempotent" property: nothing is lost by waiting one cycle.

If no commits this tick: continue to Phase 5.

Phase 5 — Queue auto-merge (gated)

Re-fetch PR metadata — state may have moved during the tick:

gh pr view "$PR_NUM" \
  --json statusCheckRollup,reviews,mergeStateStatus,mergeable,headRefOid \
  > /tmp/babysit-pr-$PR_NUM-post.json

#### The skill-level merge gate (why this exists)

gh pr merge --auto is GitHub's queue mechanism — it fires the merge as soon as branch-protection's required checks are green and required approvals are in. That sounds safe, and on a repo with airtight branch protection it is. But two real-world conditions break it:

1. Org bypass / admin capabilities. A user with bypass permissions effectively short-circuits parts of branch protection. With a permissive "required" list, auto-merge can fire even though non-required checks are still pending or failing.
2. Loose "required" lists. Most repos run more CI than they list as required. Lint, scan, e2e, coverage — all real quality gates the team wants green, none of them in the required set. GitHub's auto-merge ignores them.

The skill cannot fix branch protection from inside a tick, and it must NOT trust it. So Phase 5 enforces its own gate: every check must be terminal-green (`SUCCESS`, `SKIPPED`, or `NEUTRAL`) before the skill calls `gh pr merge --auto` at all. If anything is FAILURE, CANCELLED, STALE, TIMED_OUT, ACTION_REQUIRED, IN_PROGRESS, QUEUED, PENDING, EXPECTED, or null, do not queue. The next tick re-evaluates.

The only states GitHub uses to mean "explicitly non-blocking" are SKIPPED (the job didn't run for this PR — e.g. path-filtered) and NEUTRAL (the action ran and produced an advisory result). Everything else is, for our purposes, "not green yet." This is stricter than GitHub's branch-protection logic on purpose.

#### The gate

GREEN_STATES='["SUCCESS","SKIPPED","NEUTRAL"]'

NOT_GREEN=$(jq -r --argjson green "$GREEN_STATES" '
  .statusCheckRollup
  | map({
      name: (.name // .context // "<unknown>"),
      conclusion: (.conclusion // .status // "PENDING")
    })
  | map(select(.conclusion as $c | ($green | index($c)) | not))
  | map("  - \(.name): \(.conclusion)")
  | join("\n")
' /tmp/babysit-pr-$PR_NUM-post.json)

if [ -n "$NOT_GREEN" ]; then
  echo "Auto-merge BLOCKED — not all checks are terminal-green:"
  echo "$NOT_GREEN"
  # Do NOT call gh pr merge. The next tick re-checks and queues if/when clean.
  CHECKS_GATE_PASSED=0
else
  CHECKS_GATE_PASSED=1
fi

# Mergeability gate — UNKNOWN means GitHub is still computing; don't race it.
MERGEABLE=$(jq -r '.mergeable' /tmp/babysit-pr-$PR_NUM-post.json)
if [ "$MERGEABLE" != "MERGEABLE" ]; then
  echo "Auto-merge BLOCKED — mergeable=$MERGEABLE (need MERGEABLE)"
  CHECKS_GATE_PASSED=0
fi

# mergeStateStatus gate — `BLOCKED`, `BEHIND`, `DIRTY`, `UNKNOWN` all mean "wait."
# Only `CLEAN` and `HAS_HOOKS` (clean + non-blocking pre-merge hooks) are queue-safe.
MSS=$(jq -r '.mergeStateStatus' /tmp/babysit-pr-$PR_NUM-post.json)
case "$MSS" in
  CLEAN|HAS_HOOKS) ;;
  *) echo "Auto-merge BLOCKED — mergeStateStatus=$MSS"; CHECKS_GATE_PASSED=0 ;;
esac

If CHECKS_GATE_PASSED=0: skip the gh pr merge call entirely and write the blocked-on reason into the tick summary. The PR stays open; the next tick re-evaluates from clean state. No fallback. No `--admin`. No plain `gh pr merge` without `--auto`.

#### Queueing (only if gate passed)

if [ "$CHECKS_GATE_PASSED" = "1" ]; then
  # Pick the merge style the repo actually allows. Squash preferred.
  STYLES=$(gh api "repos/$OWNER/$REPO" \
    --jq '{squash: .allow_squash_merge, rebase: .allow_rebase_merge, merge: .allow_merge_commit}')
  STYLE_FLAG=""
  case "$STYLES" in
    *'"squash":true'*) STYLE_FLAG="--squash" ;;
    *'"rebase":true'*) STYLE_FLAG="--rebase" ;;
    *'"merge":true'*)  STYLE_FLAG="--merge" ;;
  esac

  gh pr merge "$PR_NUM" --auto $STYLE_FLAG --delete-branch \
    || echo "auto-merge queue failed — see error; will retry next tick"
fi

--auto is the only acceptable merge mode. It persists in GitHub's state, so the loop doesn't need to be running at the moment GitHub decides to fire — and it still respects branch protection on the GitHub side, on top of the skill's own gate.

Forbidden flags / patterns — these explicitly bypass the gate and must never appear in this skill:

• --admin on any gh pr merge invocation. With org bypass, --admin will merge over red checks. The whole point of this gate is to refuse to do that.
• gh pr merge without --auto (immediate merge — no waiting on approvals or any check the skill didn't already verify).
• gh api ... PUT /repos/.../pulls/.../merge direct calls (sidesteps gh pr merge entirely).
• git push origin HEAD:$BASE_REF to land changes outside the PR flow.

Idempotent — calling gh pr merge --auto on an already-queued PR is a no-op; calling after merge errors cleanly (Phase 0 of the next tick handles "already merged").

Phase 6 — Tick summary

Print a compact summary the user can read at a glance. The auto-merge line MUST reflect the actual gate state, not just whether the gh pr merge --auto call succeeded:

PR #123 — <commit-subject>
Branch: <head>  (up to date with origin/<base>)
Checks: 9/10 terminal-green (<job-name>: IN_PROGRESS — fix attempted in a1b2c3d)
Reviews: 1 approval, 2 unresolved comments → addressed 2 this tick
Auto-merge: NOT QUEUED — gate failed (<job-name> not yet green)
Next tick in 5m — will re-check <job-name> after fresh CI run.

When the gate passes:

Auto-merge: queued (squash, delete-branch) — all 10 checks terminal-green, mergeable=MERGEABLE

When commits were just pushed:

Auto-merge: deferred (commits pushed this tick — fresh CI must run before queue is safe)

The gate-state line is the single most important piece of feedback the user gets. If a tick ever queues auto-merge while a check is red or pending, that's the bug this skill exists to prevent — surface it loudly.

Write the same summary to state.last_tick.summary. Subsequent ticks can compare against this to detect churn — same fix attempted on the same job for N ticks → escalate permanently.

Safety rails

Hard stops. If any trips, the tick writes a clear reason to the summary and exits. Don't try to be clever around them — they exist because the alternative is silent corruption of shared state.

• No `gh auth` → exit, tell user to run gh auth login.
• PR's base branch IS the head branch (malformed PR) → exit with clear message.
• A commit would touch .env*, *.pem, *.key, *.pfx, *credentials*, *secret*, daemon.token, *.keystore → exit. Secrets cannot be automatically remediated.
• Rebase produces conflicts → enter the autonomous resolver (Phase 1). Push only on git push --force-with-lease if every conflict resolved AND the post-rebase test suite is green. If a cap trips (>20 files, >15 min, ≥3 reconflicts of the same file) OR the post-rebase suite goes red → git reset --hard origin/$HEAD_REF, set NEEDS_MANUAL_REBASE=1. Next tick retries (base may have moved or the conflict surface may have shrunk). After 3 consecutive resolver failures on the same base SHA: escalate permanently — the divergence is judgment-heavy and a human needs to drive it.
• Any push would `--force` (not --force-with-lease) → abort. The only legitimate force is after an intentional local rebase, which always uses --force-with-lease.
• Pre-commit hook rewrites > 10 unrelated files → revert, escalate. Usually a mis-configured global formatter; don't amplify.
• Same CI job has failed 3 ticks in a row with 3 different fix attempts → stop attempting that job (auto-merge stays queued). Write STUCK: <job> to summary; the human sees this on the next log line.
• CODEOWNERS file modified in this PR → skip Phase 3 entirely. Review policy changes need human sign-off, not bot replies.
• *PR branch is `main` / `master` / `release-please-`** → malformed input; exit. The skill never operates against protected release branches.
• Stack detection returned `unknown` AND Phase 2 wants to fix code → skip code fixes, still run Phase 3 (reviews) and Phase 5 (auto-merge). Log the stack-unknown reason so the user can add support or supply config.
• Caller has org bypass / admin capabilities → still respect the Phase 5 merge gate as the source of truth. NEVER pass --admin to gh pr merge. NEVER call the merge endpoint directly (gh api PUT /repos/.../pulls/.../merge). NEVER push to the base branch to land changes outside the PR. Bypass capability is a footgun, not a tool — the entire point of running this loop is to ship green PRs, and "merge over red checks because I can" defeats it. If the user explicitly says "merge anyway, I know it's red," that's a manual gh pr merge --admin they run themselves outside the loop; the skill never does it.
• Any check is `IN_PROGRESS`, `QUEUED`, `PENDING`, or has `null` conclusion at the moment of the Phase 5 gate → do not queue auto-merge. Treat "still running" as "still red" until it terminates green. The loop will re-evaluate in 5 minutes.
• `COMMITS_PUSHED_THIS_TICK=1` → unconditionally skip Phase 5 this tick. The pushed HEAD has not been validated by CI yet, and statusCheckRollup is briefly stale (still showing the previous commit's checks). Queueing on stale-green checks is the canonical way an auto-merge fires before fresh CI has run.

Composition with other skills

• `/go` opens the PR initially. /babysit-pr picks up after that. Don't re-invoke /go inside a tick — it includes a simplify pass that's too expensive per tick and would churn the diff reviewers are reading.
• `/loop` is the pairing mechanism. Documented usage: /loop 5m /babysit-pr <PR#>. The skill is designed to be fired repeatedly; a single invocation without /loop is a valid one-shot "check and fix what you can right now" mode.
• `simplify` is deliberately NOT called per tick — large mutation pass, belongs in /go before the PR opens, not mid-review.

Design rationale (the why)

• Why pattern-match instead of a hardcoded job table? CI pipelines rename and renumber jobs all the time ("PR Lint (Frontend)" → "Frontend Lint" → "ui / lint"). A pattern-match on the keyword (lint) survives the rename; a hardcoded row doesn't. The skill treats the pattern as a classification heuristic, not a guarantee — the actual fix command comes from stack detection, which is rooted in the repo's own file shape.
• Why stack-detect the fix command? Because lint means cargo clippy --fix in a Cargo project and pnpm biome check --write in a pnpm+uv monorepo — same category, different command. Wiring the command to stack instead of job-name means one set of rules handles any project that matches a known stack.
• Why blind-fix review comments (user-confirmed)? In small-team or single-maintainer contexts, reviewer comments are already filtered — they're deliberate and actionable. Triage-loops add latency and churn. If a reviewer leaves a bad comment, the worst case is a single mechanical commit that can be reverted. The pattern trusts the reviewer.
• Why one fix category per tick? Each push triggers a new CI run, and the tick must give CI time to tell the truth. Two fixes pushed together mask each other ("did my change fix it, or did the rerun?"). Five minutes between ticks is enough for most CI to converge on one class of fix.
• Why caps of 3 commits / 5 comments per tick? Bounded ticks are debuggable ticks. A tick that does too much becomes hard to audit; the human watching the loop can't tell what actually changed. Short ticks + 5m cadence means each tick has one story the user can read.
• Why `--auto` merge instead of gated + tick-triggered merge? --auto persists in GitHub's state. If the loop stops running (crash, restart, user closes laptop), the PR still merges when conditions land — no dependency on the tick being alive at the right moment. Fire-and-forget is the right property for a background loop.
• Why a skill-level gate on top of `--auto`? --auto only respects branch-protection's "required" set, and that set is almost never the full picture. A repo with bypass capabilities or a permissive required list will let --auto fire while non-required jobs (lint, scan, e2e) are still pending or red — exactly the symptom this skill exists to prevent. The skill therefore enforces its own gate before queueing the auto-merge: every check must be SUCCESS, SKIPPED, or NEUTRAL, mergeable must be MERGEABLE, and mergeStateStatus must be CLEAN / HAS_HOOKS. If any condition fails, the skill simply doesn't queue this tick — the next tick re-evaluates from clean state. The gate is defense-in-depth: branch protection is the second line, but the skill's own veto is the first.
• Why never use `--admin` / direct merge API calls? The whole reason this loop exists is to land green PRs. --admin is a sledgehammer that merges over red checks; using it from inside a background loop turns an aid into a footgun, multiplied across every PR the loop touches. If a human decides "this red check is wrong, ship it," they should run gh pr merge --admin themselves, after a moment of conscious thought. A /loop 5m is the wrong place for that judgment call.
• Why skip Phase 5 on a tick that just pushed? GitHub's statusCheckRollup is briefly stale after a push — for tens of seconds it can still reflect the previous commit's checks while the new checks haven't been registered yet. Queueing auto-merge against that stale-green state is the canonical race that lets a PR merge before fresh CI has even started. Deferring the queue by one tick (5 minutes) makes the race impossible: by the next tick, the new HEAD's checks are visibly running, and the gate refuses to queue until they go green.
• Why squash? The PR has accumulated intermediate fix commits from Phase 2 + review-reply commits from Phase 3. Those are interesting during review, noisy on main. One squashed commit per PR keeps main readable and feeds Conventional-Commits release tooling cleanly.
• Why worktree instead of checking out in-place? Because /loop runs in the user's session while they're doing something else. Swapping branches under them destroys their working state; a sibling worktree keeps both realities alive.
• Why track `processed_comment_ids` in a state file? GitHub's comment API has no "I've handled this" flag (thread resolution is separate and requires UI interaction). Without local state, every tick would replay every comment. With state, each tick only sees comments newer than the last.
• Why is the test suite the gate for AI-resolved conflicts and major-version bumps? Because it's the only signal we have that a mechanically applied fix is also a behaviorally correct fix. Conflict markers tell us what the two sides disagreed about; the test suite tells us whether the resolution still does what the code is supposed to do. A green suite isn't proof of correctness, but it is strictly stronger than "the diff looked reasonable" — which is what an ungated AI resolver would amount to. The gate raises the floor from "coin flip" to "as good as the existing tests can verify," and that's the bar at which a background loop becomes safe to leave running.
• Why bump CVEs aggressively (transitive, base-image, even across majors) when the old policy was conservative? The old policy ("direct deps within major only") escalated the majority of real-world CVEs back to humans, which collapses the unattended-loop premise — the loop becomes a notification system, not an autonomous one. Three things make aggressive bumps safe now: (1) the local test gate runs the full suite before the push, so a behavior-breaking bump never reaches CI; (2) major-bump intersection check refuses bumps whose blast radius is the PR's own work, where tests are least likely to catch a regression; (3) on any failure we revert atomically (git reset --hard HEAD~1) rather than try to "fix forward." The default mode is now "try the bump, prove it still works, ship it" — and "give up cleanly" is one revert away if anything looks wrong.
• Why is `--force-with-lease` after autonomous conflict resolution OK when force-push is generally a red flag? A lease isn't a force in the dangerous sense — it refuses if the remote tip moved after our fetch. So if the user has pushed something concurrently (their own conflict resolution, a manual fix, etc.), the lease fails and our push aborts, leaving their work intact. The remote-side history is rewritten only when we are demonstrably the most recent writer. Combined with the post-rebase test gate, the worst-case outcome of a bad resolution is "the PR's history is rewritten with a green-but-wrong resolution," which is the same risk profile as the human running the same rebase locally — not a new failure mode.
• Why hard-escalate on migrations? Migration tools (Alembic, Prisma, sqlx, Diesel) all have operations a guess can corrupt — multi-head resolution, downgrade path reconstruction, naming collisions across branches. The cost of a bad mechanical fix is data corruption in production. The cost of escalating is a human reading one extra tick summary. Asymmetric downside; always escalate.

Known limitations

• Conflict resolution and major-version dep bumps are both bounded by the project's test suite. If the suite is thin or doesn't cover the conflicted/bumped code, a resolution can land that compiles and passes tests but is still semantically wrong. The skill is as careful as the suite makes it.
• Base-image bumps stay within the same minor (e.g. node:20.10 → node:20.11). Cross-minor or cross-major image bumps still escalate — stdlib and system-lib changes have too wide a behavioral surface to gate on a single test run.
• Cannot modify database migrations — wrong fix can corrupt production. Escalates.
• Cannot add missing approving reviews — if CODEOWNERS requires approval and none is present, --auto queues but never fires. User must ping the reviewer.
• Cannot bump pinned dependency schemas (e.g. "vendor schema is >30 days old" age-pin failures). Versioning decisions need human eyes on the changelog.
• Does not send Slack / email notifications. The tick summary IS the notification; user reads it in their loop output.
• Does not detect reviewer intent when a comment is mechanically actionable but strategically wrong. If a reviewer says "remove this check" and it's load-bearing, the skill will remove it. This is accepted risk under the blind-fix policy — mitigated by squash-merge-after-approval (the reviewer sees the squashed diff before approving).
• Does not coordinate across multiple PRs — each tick is scoped to one PR. Multiple /babysit-pr loops can run in parallel for different PRs without state collisions (state files are per-PR).
• Only recognizes rust-cargo and pnpm-uv-monorepo stacks today. On an unknown stack, Phase 2 falls back to rerun-or-escalate (no code fixes); reviews and auto-merge still work.