b-open-io/wait-for-ci
skills/wait-for-ci/SKILL.md
Wait for CI/CD pipelines to complete after pushing code, then act on results. This skill should be used after git push, after creating a PR, when the user says 'wait for CI', 'check if the build passes', 'monitor the pipeline', 'wait for checks', 'is CI green?', or whenever the agent needs to verify that pushed code passes CI before proceeding. Also use when an agent workflow involves push-then-verify cycles, deployment monitoring, or needs to block on CI results before taking the next step. Supports GitHub Actions, GitLab CI, and Vercel deployments.
$ install --global
skillsauthnpx skillsauth add b-open-io/prompts wait-for-ciInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: May 29, 2026, 3:26 AM69.8s4 files scanned
SKILL.md
- name:
- wait-for-ci
- description:
- Wait for CI/CD pipelines to complete after pushing code, then act on results. This skill should be used after git push, after creating a PR, when the user says 'wait for CI', 'check if the build passes', 'monitor the pipeline', 'wait for checks', 'is CI green?', or whenever the agent needs to verify that pushed code passes CI before proceeding. Also use when an agent workflow involves push-then-verify cycles, deployment monitoring, or needs to block on CI results before taking the next step. Supports GitHub Actions, GitLab CI, and Vercel deployments.
- user-invocable:
- true
Wait for CI
Wait for CI/CD pipelines to finish and get actionable results — without burning context on polling logic. Everything deterministic is handled by scripts. Your job is to spawn them and act on what comes back.
Why Scripts Handle the Waiting
Polling a CI system is pure mechanics — no reasoning needed. The wait-ci.sh script handles all the waiting, retrying, and status parsing. Running it as a background task means you can do other work while CI runs, and you get notified with structured JSON when it finishes.
Quick Start
Two steps: detect, then wait.
Step 1: Detect CI System
bash <skill-path>/scripts/detect-ci.sh /path/to/project
Returns JSON like:
{
"ci": "github-actions",
"deploy": "vercel",
"config_file": ".github/workflows/ci.yml",
"workflow_count": 3,
"repo": "owner/repo",
"branch": "feature-x",
"sha": "abc1234",
"tools": { "gh": true, "glab": false, "vercel": true }
}
If ci is "unknown", tell the user no CI configuration was found and ask what they use.
If the required CLI tool is missing (tools.gh, tools.glab, or tools.vercel is false), tell the user to install it before proceeding.
Step 2: Wait as a Background Task
Run the wait script with run_in_background: true so you stay unblocked:
bash <skill-path>/scripts/wait-ci.sh github-actions \
--repo owner/repo \
--branch feature-x \
--sha abc1234 \
--timeout 600
The script blocks until CI finishes (or times out), then outputs JSON:
{
"ci": "github-actions",
"repo": "owner/repo",
"branch": "feature-x",
"sha": "abc1234",
"status": "completed",
"conclusion": "failure",
"elapsed_seconds": 142,
"details": "Failed: lint: failure; | Logs: error: unused variable...",
"url": "https://github.com/owner/repo/actions/runs/12345"
}
Step 3: Act on Results
When the background task completes, you get the JSON. Use it:
| conclusion | What to do |
|---|---|
| success | Report success. Proceed with next steps (merge, deploy, etc.) |
| failure | Read the details field for failed jobs and log excerpts. Fix the issue and push again. |
| cancelled | Tell the user CI was cancelled — they may need to re-trigger. |
| timeout | CI took too long. Link the user to the run URL so they can check manually. |
| missing_tool | Tell the user which CLI tool to install. |
| no_run_found | Push may not have triggered CI. Check if workflows exist for this branch. |
When CI fails, the details field contains the failed job names and a log excerpt (last 30 lines of the failed step). This is usually enough to identify the issue without manually opening the CI dashboard.
Monitoring Both CI and Deployment
Some projects have both CI (GitHub Actions) and deployment (Vercel). You can run both in parallel as separate background tasks:
# Background task 1: CI
bash <skill-path>/scripts/wait-ci.sh github-actions --repo owner/repo --branch main
# Background task 2: Deployment
bash <skill-path>/scripts/wait-ci.sh vercel --branch main
Each will notify you independently when done.
Typical Agent Workflows
Push-and-Verify
After pushing a fix or feature:
- Run
detect-ci.shto get the CI config - Spawn
wait-ci.shas a background task - Continue working on other tasks (or tell the user you're waiting)
- When notified, report the result or fix failures
Iterative Fix Loop
When CI fails:
- Read the failure details from the JSON output
- Fix the issue in code
- Commit and push
- Spawn a new
wait-ci.shbackground task for the new commit - Repeat until green
Pre-Merge Gate
Before merging a PR:
- Spawn
wait-ci.shfor the PR branch - Only proceed with merge when
conclusionissuccess - If it fails, fix and re-push instead of merging broken code
Supported CI Systems
| System | CLI Required | Detection | Wait Method |
|---|---|---|---|
| GitHub Actions | gh | .github/workflows/*.yml | gh run watch (blocking, efficient) |
| GitLab CI | glab | .gitlab-ci.yml | glab ci status (polling) |
| Vercel | vercel | vercel.json or .vercel/ | vercel inspect (polling) |
GitHub Actions uses gh run watch which is a native blocking wait — no polling overhead. GitLab and Vercel use periodic polling at 15-second intervals.
Options
| Flag | Default | Description |
|---|---|---|
| --repo | From git remote | Repository in owner/repo format |
| --branch | Current branch | Branch to monitor |
| --sha | Current HEAD | Commit SHA to match |
| --timeout | 600 (10 min) | Max seconds to wait before timing out |
| --poll | 15 | Seconds between status checks (GitLab/Vercel only) |
Related Skills
b-open-io/claudex
tools
VerifiedTrustedCommunity
This skill should be used when a Claude Code session needs to keep working after Anthropic usage runs out, or when the user asks to run the Claude Code harness on GPT-5.6 Sol. Trigger phrases include "my Anthropic usage ran out", "I'm out of Claude usage", "usage limit reached, what now", "keep working on another model", "run Claude Code on GPT-5.6 Sol", "use GPT-5.6 Sol as the model", "set up claudex", "claudex isn't working", "route the harness through CLIProxyAPI", or "bill against my ChatGPT/Codex subscription". It stands up a local proxy so the Claude Code CLI runs on OpenAI's Codex backend as an escape hatch, and diagnoses that setup when it drifts. macOS + Homebrew.
14SKILL.mdUpdated Jul 17, 2026
b-open-io/visual-wayfinder
testing
VerifiedTrustedCommunity
This skill should be used when the user asks to "open Visual Wayfinder", "answer a Wayfinder ticket visually", "turn this decision into a configurator", "show Wayfinder choices as a dashboard", "prototype the Wayfinder questionnaire", or wants interactive choice cards, tradeoff controls, rankings, ranges, toggles, and consequence previews for one active Wayfinder decision. It wraps the Wayfinder skill and JSON Render; it never replaces the tracker or resolves more than the active decision.
14SKILL.mdUpdated Jul 16, 2026
b-open-io/visual-proposal
development
VerifiedTrustedCommunity
This skill should be used when the user asks to "make a visual proposal", "write this up so I can share it", "present these options visually", "diagram the trade-offs", "turn this plan into something reviewable", or requests a shareable design pitch, architecture proposal, RFC, options comparison, or visual roadmap for work that has not been built. It produces one self-contained, theme-aware HTML page led by grounded diagrams. Use visual-review instead for completed code changes; do not use this skill for internal task tracking.
14SKILL.mdUpdated Jul 16, 2026
b-open-io/plugin-settings
tools
VerifiedTrustedCommunity
This skill should be used when the user asks to "add plugin settings", "make a plugin configurable", "store per-project plugin configuration", "use settings.local.json", "create a plugin state file", "expose skill settings in Agent Master", or "add a skill interface". Distinguishes official Claude Code settings from project-owned configuration and documents bOpen Agent Master skill interface discovery.
14SKILL.mdUpdated Jul 16, 2026