Commit

9. Monitor the PR

Green CI is not an exit condition. Monitor every PR until it merges or closes, the user tells you to stop, or a 12-hour wait times out.

Before the first wait, read every current issue comment, inline review comment, and submitted review once, then address anything actionable. This is a one-time inspection, not a monitoring loop. The comment and review arms establish a baseline when they start and wake only for later new or edited feedback.

If Loom is available, set one honest status immediately before waiting:

loom status set --tag ok --message "waiting for PR #<N> events"

Do not refresh that status while nothing changes. Invoke one wait_for.py process in the foreground and keep it attached until it exits:

uv run scripts/ci/wait_for.py --timeout 12h \
  "github.ci <N>" "github.pr <N>" \
  "github.pr_comment <N>" "github.review <N>"

The command's --timeout 12h is the only timeout. Do not background or detach the process, wrap it in a shell timeout, or give the command runner or agent a shorter deadline. A tool reporting that the command is still running does not end the foreground wait. Give the process handle back to the runtime's blocking wait/resume facility and continue waiting for that same process to exit. Repeat the blocking resume as often as the execution interface requires.

github.pr covers terminal merged/closed state, merge conflicts, ready-for-review transitions, and review-decision changes. It does not inspect comment or review bodies, so it does not replace github.pr_comment or github.review. Keep all three arms. Monitoring must not use a raw poll shell expression, gh pr checks --watch, or repeated gh pr view calls.

The wait owns its exponential backoff. While it is running:

• remain silent until it returns an event, timeout, or error;
• do not poll GitHub manually;
• do not launch another wait_for.py;
• do not narrate unchanged CI, review, or merge state;
• resume a yielded process handle only with another blocking wait on that same handle; do not treat the yield as an event.

The command prints one JSON object and exits: 0 means an arm fired, 2 means the overall timeout elapsed, and 1 means the wait failed. An event is not always a successful verdict. Read result.conclusion for github.ci and result.reasons for github.pr.

Act on the event, read any feedback that arrived concurrently, then re-arm:

1. github.ci — on failure, read the failing job log and fix the regression. A failure in an untouched file is not automatically pre-existing: confirm the same job fails on main independently before treating it as unrelated. Once CI finishes, omit github.ci from the next wait because its terminal result would fire immediately. Add it back after a push starts a new run.
2. github.pr — merged and closed are terminal. Resolve conflicted before re-arming; an unchanged conflict is intentionally reported again by a fresh wait. ready_for_review and review_decision describe review-state changes in the attached snapshots. When review_decision fires, inspect the submitted review because the lifecycle payload does not include its body.
3. github.pr_comment / github.review — address every actionable human and agent comment. Prefix agent-authored replies with 🤖 and resolve the thread. The default significant-comment filter ignores the authenticated user's comments, review-bot progress placeholders, clean verdicts, wrappers, Loom's exact Working on this in loom: <session URL> acknowledgement, and Loom access-control replies addressed to a bot.
4. Timeout — report the last statuses in the timeout payload and hand off. Do not replace the completed 12-hour block with manual polling.

Re-arm after every non-terminal event. Once CI finishes, omit github.ci so its terminal result does not fire immediately; keep github.pr, github.pr_comment, and github.review armed for later feedback. Read current feedback once before each re-arm so simultaneous events are not absorbed into a new baseline without being handled.

A question requiring user input pauses monitoring: raise attention, ask the question, and resume after the answer. Otherwise the only exit conditions are a merged or closed PR, an explicit request to stop, or a 12-hour timeout.