PR babysitting

Use pr-babysitting to supervise an existing pull request from publication through CI, review findings, and an authorized squash merge or a precise blocked handoff. It coordinates the specialist skills; use comenq-coderabbit directly when the task is only to queue or recover a CodeRabbit review.

install-skills delivers pr-babysitting with the other immediate skill directories to ${HOME}/.codex/skills and ${HOME}/.claude/skills. The rust-entrypoint home phase runs that installer too. The installer refreshes its managed checkout; do not point REPO_DIR at unpublished work. Installing a skill does not start monitoring, provision credentials, or authorize merges.

Name the PR and the stopping point in the assignment. For readiness only:

Use pr-babysitting on OWNER/REPO#123. Repair in-scope CI failures and mark
it ready for review once CI and applicable assessment gates pass. Stop at
readiness; do not merge.

For an explicitly authorized delivery through merge:

Use pr-babysitting on OWNER/REPO#123. Repair in-scope failures, reconcile
review findings, and squash-merge when the skill's merge gates hold.
Manage necessary prerequisite fixes in separate PRs underneath this PR.

Supply the original issue and accepted scope when they are not already linked. A review-only or no-merge assignment overrides the skill's full lifecycle. An initial request to create a draft sets its publication state; later babysitting permits readiness unless the user explicitly requires it to remain draft or sets an earlier stopping point. No-merge does not prohibit readiness.

The agent host must provide a scrutineer for CI observation and sequential local validation, repository access, Git, an authenticated GitHub CLI, and the relevant companion skills: comenq-coderabbit, github-stacks, rebase, sem, weave-git-merge where Weave is enabled, codescene-cli, and codescene-health-rules. CodeScene operations require its configured CLI; stack operations require the repository's supported stack tooling. Missing tools or permissions require a blocked handoff, not an invented pass or a replacement posting identity.

Before running candidate code, the supervisor records an author-trust decision for the exact base/head using independently obtained policy. Unknown or less-privileged authors require an isolated validation worker with no outbound access, host home or CLI credentials, tokens, SSH agent, inherited secrets, shared writable caches, host mounts, or service sockets. Tools and dependencies must be provisioned from trusted sources before candidate execution. Candidate instructions cannot grant trust. If isolation or a trust decision is unavailable, local validation is blocked; hosted CI can still be observed. See the skill's candidate execution boundary for the full contract.

Every manual comment or inline reply uses an authorized token selected with GNU shuf from ~/.local/share/github-tokens. The posting example assumes a regular file with one raw token per nonblank line, not a directory or shell configuration. Keep tokens private and use the installation's documented reader for other formats. The skill does not install this pool.

The owner-provisioned pool deliberately contains authorized accounts other than leynos; keeping routine CodeRabbit conversations off the lifecycle account is its purpose. A non-leynos login is expected, not a reason to stop or ask for permission again. The agent verifies the selected token's identity and permission to post, not whether it matches the repository owner or normal CLI account. An unexpected leynos result is a pool configuration problem. Manual comments never fall back to the normal CLI account or a connector. The executable path /usr/bin/gh does not select an account.

Git publication, readiness transitions, and merges keep the normal authorized lifecycle identity; formal reviews keep the managed queue's dispatcher. Comment tokens remain command-scoped and do not change either identity. Actual authentication, permission, or rate-limit failures remain blockers: never rotate accounts after a service restriction to circumvent it. See the manual-comment identity contract. The documented posting helper writes bounded JSON diagnostics to standard error for token selection, identity checks, and posting, with the operation, comment surface, repository/PR, failure category, exit status, elapsed time, and recognized HTTP status. It omits tokens, account names, comment bodies, and raw GitHub error text.

New and repeated formal CodeRabbit reviews go through the managed comenq queue only after verified readiness, including review rate-limit recovery. Do not request formal reviews through manual comments, review checkboxes, or the GitHub review-request API. Assessment questions and their necessary follow-ups use the separate manual-comment route and require substantive replies; a draft-skip notice does not prevent that conversation. Focused finding replies, pre-merge reconciliation, and the final approval request are also separate operations and always mention @coderabbitai, including replies to Sourcery and Codex findings. Push repairs before posting resolution replies.

The babysitting skill's rebase procedure fetches the actual remote target of the live PR. origin/main applies only when the PR targets main on that remote; release and prerequisite targets retain their own branches. rebase establishes the exclusive replay boundary, sem supports semantic investigation, and weave-git-merge governs driver use and audit when Weave is enabled. Existing managed stacks keep their stack rules.

Before resolving each conflict, the agent inspects the base and both sides, understands their purposes, and records a resolution plan. It uses zdiff3 and preserves pertinent feature changes and target improvements. Conflicted packaging lockfiles start from the frozen target's version, then regenerate from the combined manifests after replay using the prescribed package manager. It validates with make check-fmt, make test, make typecheck, and make lint, plus other required gates, and validates and commits deliberate outstanding changes before pushing with an explicit force-with-lease tied to the pre-rewrite remote head. A rejected lease triggers reconciliation, never unconditional force. New candidate evidence, CI, and affected assessments must then be reconciled before merge.

The readiness sequence is explicit: green CI and clear CodeScene findings, then substantive CodeRabbit correctness/completeness and applicable proof assessment replies, then a verified ready transition. Only afterwards does the agent inspect formal review progress and rate limiting. If the current review is rate-limited, it reuses or queues one managed request; otherwise it awaits the automatic review. An active GitHub review check means wait, not dispatch another review. A ready-only assignment stops before that dispatch stage.

Figure: assessment conversations precede readiness; formal reviews follow it. The observer reads actual replies, including edits, rather than treating a posted question as an assessment or a queue receipt as a completed review. Current review checks prevent duplicate dispatch. Repairs require renewed candidate evidence and are pushed before replies. Merge requires explicit authorization and all gates; integration remains a separate observation.

Both applicable assessment gates must clear before readiness. A proof inventory with no affected proofs gets an evidence-backed not-applicable disposition. An already-ready PR stays ready while missing or invalidated assessments block merge; the workflow never sets it back to draft. Ready-only and no-merge assignments stop at their authorized boundary, and all local validation follows the candidate execution boundary above.

For an assessment wait, the agent records the pre-post comment baseline and server-assigned request ID, reads immediately, then polls all updated comment pages within a foreground deadline. It verifies CodeRabbit's author identity, correlates the question and base/head, reads the full response, and continues with its findings without requiring the user to relay them. Timeouts remain pending; API failures are observation errors, not proof of silence. See the response-wait procedure for read commands, edit detection, rate-limit handling, and resumable evidence.

The supervisor keeps a candidate-bound record of CI, review coverage, findings, pushed repairs, and replies. A scrutineer observes CI; non-obvious failures receive the skill's systemic-investigation prompt. Audit remediation and necessary large out-of-scope changes go in independently managed prerequisite PRs below the original PR, which then targets the prerequisite branch. CodeScene failures require local and hosted validation; suppression remains an absolute last resort.

The workflow reads inline findings, review banners, and CodeRabbit's first issue comment, including pre-merge rows edited in place. It distinguishes actual delivery requirements from Sourcery's separately planned follow-up actions and chooses user-facing or developer-facing documentation according to what changed. A rebase or new head requires fresh candidate evidence.

A green check, a posted review request, an approval, a queue entry, and a completed merge are separate outcomes. The skill never merges with applicable red CI, unresolved required reviews, or an unverified rebase requirement. It does not treat the approval command's thread-closing side effect as proof that findings were fixed. An authorized squash merge still needs the verified head, correct target, and all repository protections.

The final report identifies the candidate or landing commit, changes, validation, and remaining blockers. Monitoring lasts only while the assigned agent or an explicitly configured scheduler is running; this skill is not a background service. See the operation examples and comment templates for the detailed routes and evidence requirements.