babysit

DLC: PR Babysitter

Monitor a PR on a loop: check CI, auto-rebase, auto-fix CI failures, and delegate review comment handling to dlc:pr-check. Use with Remote Control to monitor from your phone.

Usage: /loop 10m /dlc:babysit (auto-detect PR) or /loop 10m /dlc:babysit 253

Why This Matters

Bot reviewers (Copilot, CodeRabbit, Gemini) post new comments on every push — this is by design, not a bug in your workflow. A typical PR goes through 3-8 review-fix cycles before converging to zero unresolved items. Each cycle you run is measurable progress: fewer comments, better code, closer to merge-ready.

The human set up this loop because they trust you to shepherd the PR to completion autonomously. When the comment count drops from 12 to 5 to 2 to 0 across cycles, that's excellent work — not busywork.

Notification Rules

Only fire PushNotification for errors that need human attention and completion (PR ready to merge). Routine actions (rebase, lint fix, CI retry, re-request review) are silent. PushNotification is always the sanctioned channel — never substitute with a Notify: print line or echo, because print output does not ping the user's device.

Deduplication

Notifications are deduplicated via a state file at .dev/dlc/babysit-<PR_NUMBER>.state. The file contains a single-line status key:

• ci_failing:<sorted_check_names> (e.g., ci_failing:build,lint)
• rebase_conflict:<sorted_file_list>
• merge_conflict
• pending_human:<count> (count-only dedup, e.g., pending_human:2)
• unresolved:<count>
• unresolved:<count>,ci_failing:<sorted_check_names>
• ready
• closed:<state>

Same key across cycles = no output. Write the new key after notifying. Delete the state file when self-cancelling.

Step 0: Setup

Initialize state tracking

Create .dev/dlc/ if it does not exist. Read the state file if it exists.

Detect PR

If $ARGUMENTS contains a number, use it as PR_NUMBER and fetch that PR explicitly:

gh pr view $PR_NUMBER --json number,title,headRefName,baseRefName,state,url,reviewDecision,mergeable,author

If no number is provided, auto-detect from the current branch:

gh pr view --json number,title,headRefName,baseRefName,state,url,reviewDecision,mergeable,author

If no PR exists for the current branch, stop silently.

Extract and store: PR_NUMBER, PR_TITLE, PR_BRANCH, BASE_BRANCH, PR_STATE, PR_URL, REVIEW_DECISION, MERGEABLE, PR_AUTHOR (.author.login).

State gate: If PR_STATE is not OPEN:

• Write state key closed:<state>.
• Fire PushNotification with message PR #<number> is <state>. Babysit cancelled.
• Self-cancel (see Cancellation Pattern below) and stop.

Verify and checkout PR branch

Before any git operations, verify you are on PR_BRANCH:

CURRENT=$(git branch --show-current)
if [ "$CURRENT" != "$PR_BRANCH" ]; then
  if [ -n "$(git status --porcelain)" ]; then
    echo "ERROR: Not on PR branch ($PR_BRANCH) and worktree is dirty. Stash or commit first."
    exit 1
  fi
  gh pr checkout $PR_NUMBER
fi

If checkout fails, stop. Do not proceed with git operations on the wrong branch.

Step 1: Check CI Status

Query the named checks and the raw workflow runs for the PR — the two views can disagree. An Action workflow can be in_progress, queued, waiting, requested, or pending before (or without ever) registering a named check status, so relying on gh pr checks alone will prematurely classify CI as "settled" while bot reviewers are still writing comments. Derive PR_HEAD_SHA from GitHub via gh pr view --json headRefOid so the gh run list query is pinned to the PR's current HEAD commit even if the local checkout falls behind; gh pr checks $PR_NUMBER is still read from the PR as usual. The status != "completed" filter catches every non-terminal run state (queued, in_progress, waiting, requested, pending). --limit 100 keeps reruns and multi-workflow PRs from falling outside the default 20-run window. Treat either source reporting activity as a pending state.

PR_HEAD_SHA=$(gh pr view $PR_NUMBER --json headRefOid --jq '.headRefOid')
gh pr checks $PR_NUMBER --json name,state,bucket
IN_PROGRESS_RUNS=$(gh run list --commit "$PR_HEAD_SHA" --limit 100 --json status --jq '[.[] | select(.status != "completed")] | length')

Categorize each named check by its bucket field:

• Running: bucket is pending
• Failed: bucket is fail or cancel — cancelled checks are not passing per GitHub required-check semantics
• Passed: bucket is pass
• Neutral: bucket is skipping — treat as non-blocking (not a failure)

If any checks are still running OR IN_PROGRESS_RUNS > 0: Stop without printing anything. This is the normal waiting state — no point acting on incomplete results. IN_PROGRESS_RUNS > 0 catches bot-review workflows (Copilot, CodeRabbit, Codex) that execute via GitHub Actions but may not surface a named check.

If ALL checks passed or neutral (no pending/fail/cancel) AND IN_PROGRESS_RUNS == 0, or NO checks and no runs in progress: Set CI_STATUS=passing. Continue to Step 2.

If any checks failed: Set CI_STATUS=failing and record the failing check names. Continue to Step 1b (attempt auto-fix).

Step 1b: Attempt CI Auto-Fix

Do not just notify and stop when CI fails. Attempt to diagnose and fix the failure first.

Read CI logs

Get the HEAD SHA, then fetch ALL non-success runs scoped to that specific commit:

HEAD_SHA=$(git rev-parse HEAD)
gh run list --commit $HEAD_SHA --json databaseId,conclusion --jq '[.[] | select(.conclusion != "success" and .conclusion != "skipped" and .conclusion != "neutral" and .conclusion != "")] | .[].databaseId'

For each failing run, read its logs:

gh run view <RUN_ID> --log-failed 2>&1 | tail -200

Collect and combine log output from all failing runs before classifying.

If no failing runs are found (e.g., the check is from an external review tool like Codacy, CodeRabbit, or Qodo that reports status via the Checks API but has no GitHub Actions run logs): Skip classification — there is nothing to auto-fix. Continue to Step 2 with CI_STATUS=failing.

Classify and fix

Analyze the log output and classify the failure:

Lint / format errors (eslint, prettier, ruff, clippy, etc.):

1. Run the project's lint-fix command (look for it in package.json scripts, Makefile, justfile, or CI config)
2. Stage, commit with message: fix: auto-fix lint errors, and push
3. Stop — CI will re-run on the new HEAD. Next cycle checks the result.

Type errors (tsc, mypy, pyright, etc.):

1. Read the erroring files and fix the type issues
2. Stage, commit with message: fix: resolve type errors, and push
3. Stop — CI will re-run.

Test failures:

1. Read the failing test output to identify which tests and why
2. Read the test files and the source files they exercise
3. Determine if the fix belongs in the source code (bug) or the test (outdated assertion)
4. Apply the fix, stage, commit with message: fix: resolve test failures, and push
5. Stop — CI will re-run.

Infrastructure / flaky failures (timeout, network, OOM, rate limit):

1. Attempt to re-run the failed jobs:

``bash gh run rerun <RUN_ID> --failed ``

1. Stop — next cycle checks the result.

Unknown / cannot diagnose: Cannot auto-fix, but do NOT stop here. Continue to Step 2 with CI_STATUS=failing. The failing checks may be resolved by pr-check (e.g., review-tool checks that clear once their comments are addressed).

Do not notify after a successful fix attempt — this is routine automation. Stop silently and let the next cycle check the result.

Stop vs. continue rule for Step 1b: Only stop if you pushed commits (after applying a fix) or re-ran jobs with gh run rerun — either action makes the current CI state stale, and the next cycle should evaluate the fresh result. If neither commits were pushed no