メニュー
Watch a CI run's jobs to completion without idling or hand-writing a poll loop. Use when a dispatched or pushed build takes minutes to finish and its per-job results decide the next step.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
SOC 職業分類に基づく
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/aspiers/ai-config --skill watching-ci-runsコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SKILL.md を表示中
Prepare and publish upstream issues, feature requests, discussions, pull or merge requests, and patch submissions in the channel the canonical project expects. Use when reporting a problem upstream, requesting a feature, contributing a change, or asking to submit upstream.
Summarises the current session for a human who has not read it, or cannot remember it, and needs to get back up to speed fast. Use when the user asks for a TL;DR, a catch-up, a recap, or to be reminded where things got to, especially when they have been away or working in other sessions.
Review every Beads issue waiting on a person, one at a time, using the interactive questionnaire UI rather than plain-text prompts. Use when asked to go through blockers, clear the human queue, answer beads waiting on the user, triage `bd human list`, or unblock agent work that needs a decision.
| name | watching-ci-runs |
| description | Watch a CI run's jobs to completion without idling or hand-writing a poll loop. Use when a dispatched or pushed build takes minutes to finish and its per-job results decide the next step. |
Native builds routinely take 10-20 minutes. Blocking on them wastes that time, and hand-rolled poll loops repeatedly get the same details wrong: emitting a line per poll, staying silent on failure, or being launched twice for one run.
Arm one watcher, then keep working.
Use the harness's event-stream monitor with the bundled script, which emits one line per job as it reaches a terminal state and exits when the run completes:
scripts/watch-run.sh <run-id> [--interval SECONDS] [--repo OWNER/REPO]
Each job result arrives as its own notification, so a failure surfaces the moment that job lands rather than when the whole run finishes. Set the monitor timeout above the expected run duration; a matrix build needs far more than the default.
The point of an event stream is that waiting costs nothing. After arming it, start the next piece of work immediately. Never sleep, poll, or re-read the output file to pass the time — a notification will arrive.
Good use of the interval: the next bead, a review of the diff just pushed, documentation the change implies, or preparing the follow-up commit. Prefer work that does not conflict with the commit under test, so a red result does not invalidate it.
Before arming, check whether a watcher for that run already exists, and stop it rather than adding a second. Two watchers on one run duplicate API calls and split the results across output files, which is how a green job goes unnoticed.
If a result arrives from elsewhere before the watcher reports, that is not a reason to start another watcher.
Emit each job's actual conclusion, whatever it is. A watcher that matches only success stays silent through a failure, and silence is indistinguishable from still-running. Ask before arming: if this run failed right now, would anything be emitted?
Tolerate transient API errors rather than dying or, worse, treating an empty response as "nothing has finished" and re-announcing every job on recovery.
Diagnose a failure from the logs already produced before dispatching anything new; CI time is a finite paid budget. A single failed job does not justify cancelling its siblings, whose independent results are often the faster diagnosis.