Babysit a PR

Keep an open PR continuously moving toward merge by reacting to two independent event streams — incoming review comments and CI status changes — as each arrives, for as long as the PR stays open. Comment fixes are delegated to resolve-pr-feedback; CI failures are delegated to debug. This skill owns the watch loop: snapshot, order, dedup, act, and decide when to keep watching, move to the next authorized managed-stack layer, or stop.

Outcome: leave the requested PR at an honest terminal, looks-ready, blocked, or budget state. For an independent PR or manual dependency chain, that target-local result is done. For a confirmed managed stack, a settled requested layer is a transition checkpoint: offer stack-wide continuation once when another immediate non-draft layer needs work; if accepted, babysit one layer at a time and stop advancement at the first draft not explicitly in scope, a human-blocked layer, the end of the stack, or the normal budget/user stop. Never infer this broader semantic scope from branch topology alone.

Non-negotiable boundaries

• Merge-readiness is never merge authorization. This skill never merges as part of babysitting; only a separate explicit user request to merge can authorize that action.
• Draft PRs are opt-in. Never review or babysit a draft merely because managed-stack traversal reaches it; a draft is eligible only when the user explicitly named that draft or explicitly included drafts in scope.
• Managed means positively confirmed membership. A managed stack exists for this workflow only when a fresh probe proves the target belongs to it and emits manager_status == "confirmed". Repository-level stack availability, a manual base/head dependency, or a failed/uncertain probe is not a managed stack.
• One semantic writer lane. Keep one active PR target and one watcher. Manager-owned mechanical propagation may update confirmed dependents, but review/CI fixes on another layer require explicit stack-wide semantic scope and proceed downstack-to-upstack, never concurrently.

The watch runs until the PR is terminal (merged/closed), a budget cap is hit, or the user stops it — not until the first thing the loop cannot do itself. An item that needs a human decision (a needs-human residual), a check left terminally red, or an unresolvable semantic conflict is parked and surfaced as a standing residual: it blocks declaring merge-ready, but it does not end the watch. You keep driving every other stream around it — a parked review thread never stops you from fixing a new CI failure or handling a fresh review round. Ending the whole loop the moment one item needs a human is the primary failure mode of this skill: the PR keeps moving (new reviews land, CI re-runs), so the watch must too. The loop only ends on a true terminal/budget stop (Step 3); a residual only pauses that item.

Honest contract: you drive the PR toward merge-ready and report when it looks ready — you cannot guarantee merge-readiness (a reviewer can always add feedback later, required checks can change). The final merge stays the user's. Anything that needs a human decision is surfaced as a standing residual and kept visible — never forced, and never a reason to abandon the rest of the watch.

"Looks ready" is signal-gated, not a timer. It is never enough that CI is green and the PR has been quiet for a while. Judge whether a review is still in flight from a set of signs — no single one is definitive, and any present one means not-ready: