When the user requests to monitor remote CI results or watch a pull request, or when monitoring CI after PR updates:
Note:
monitor_remote_ci.pyis a single long-running continuous task. It continuously watches all current and future CI runs for the PR. Do NOT launch duplicate monitoring jobs for the same PR.
- Check Existing Process: Check if a monitor script is already running for
this specific PR using
pgrep -f "monitor_remote_ci.py <pr_number>". Do NOT use a generic grep without<pr_number>, as other active agent conversations may be monitoring different PRs concurrently. If one is already running for this PR, do not start another instance. - Launch Monitoring Script: If no monitor process is active for
<pr_number>, launch the script in the background:
./.agents/skills/monitor-ci-results/scripts/monitor_remote_ci.py \
<pr_number> "<your_conversation_id>" &
✨ Autonomous Subagent Orchestration
- Background Polling:
monitor_remote_ci.pycontinuously polls both GitHub PR checks and Buildkite workflow executions in the background across new commits and CI re-runs. - Blocked Jobs: When a Buildkite job or GitHub check is in a blocked state
waiting for user confirmation, it dispatches a notification via
agentapi send-messageso the user is alerted to confirm running the job. - Failure Reporting: When any GitHub check or Buildkite job completes
with errors,
monitor_remote_ci.pydispatches a high-priority notification message reporting the failed check back to your conversation.- Soft failures (e.g.
*rolling*Bazel) are non-blocking warnings; ignore.
- Soft failures (e.g.
- Subagent Analysis: Upon receiving a failure notification message from
the monitoring script, immediately launch a separate subagent using the
invoke_subagenttool with the role "CI Failure Analyzer" to run theanalyze-ci-failureskill on the reported failure. - Autonomous Flake Retry: If the CI Failure Analyzer subagent confirms
that the failure is a transient infrastructure or network flake (e.g. disk
I/O error, 504 gateway, sandbox initialization failure), immediately and
autonomously launch a separate subagent using
invoke_subagentwith the role "CI Job Retrier" and the prompt template in.agents/skills/monitor-ci-results/retry-job-prompt.mdto run thebuildkite-retry-jobskill for<pr_number>. Do not execute the script directly; use the subagent and skill orchestration instead. Continue monitoring without pausing to ask the user.