Skip to content
Back to skills

Ci Wait

ASecurity

Wait for PR CI in a background Bash task instead of foreground polling. Use when a PR is pushed and its checks must reach a terminal state (before in_review, after a fix push, before factory done).

  • 8 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added November 5, 2026
ai-agentspythongobashtestinggit

Works with

  • terminal

Security analysis

A100/100

Scanned November 5, 2026

npx -y skills add volekerb/hivemill --skill ci-wait --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Ci Wait?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Ci Wait
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/volekerb-ci-wait/badge)](https://www.skillsdirectory.com/skills/volekerb-ci-wait)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: ci-wait
description: Wait for PR CI in a background Bash task instead of foreground polling. Use when a PR is pushed and its checks must reach a terminal state (before in_review, after a fix push, before factory done).
---

Purpose: CI takes up to 35 min and a foreground Bash call times out at 10 min, so a foreground `--watch` is re-run several times and every re-run is a turn that re-reads the whole context. One background watch costs one turn.

Follow these steps in order.

1. Start exactly one watch with the Bash tool, with `run_in_background: true`:
   `Bash(command: "gh pr checks <url> --watch --interval 60 --fail-fast", run_in_background: true, description: "Watch CI for <T>")`
2. End your turn. Do not poll, do not `sleep` (foreground sleep is blocked), do not re-read the output file, do not start other long jobs while waiting. You are re-invoked when the background-task notification arrives.
3. On the notification, read the result once: `gh pr checks <url>`. All green: continue (in_review, then `factory done`).
4. On red: check `gh pr view <url> --json mergeable` first (L-013), fix what your head caused, commit, push, then repeat from step 1 with one new watch. A red check outside your diff: tell your lead with the check name and output.

Local = fast, CI = full (docs/testing.md): CI is where the full suite, go and integration run. Locally you ran only lint and `ci/affected.py --quick`. Read a red check with `gh run view <run-id> --log-failed` (run id from `gh pr checks <url>`), reproduce with only the failing module (`python3 -m unittest discover -s tests -p test_<name>.py`), never the full suite. Never export GIT_* env (L-050). At load1 >= the load cap (gate_max_load_ratio x CPUs; exit 5 from the tool means the same) skip the local run and use the PR CI result instead (L-052/M16816): not a FAIL, not a blocker.

Rules:
- Never more than one watch per PR at a time; wait for the notification of the old one before starting a new one.
- Kill only your own background job (`kill %job` / `kill $!`), never `pkill` or `killall` (L-022).
- `gh pr merge` stays denied; merging is the judge's job.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

View all in ai-agents →

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.