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/html-to-pdf
development
VerifiedTrustedCommunity
This skill should be used when the user asks to "design a business card", "make a printable PDF", "render HTML to PDF", "generate a postcard", "build print collateral", "set up an HTML print pipeline", or needs help with bleed, safe areas, font embedding, or QR generation for print. Provides a Playwright-based pipeline with multiple bundled templates and theme variants for business cards (minimal, watercolor light, watercolor dark) and instructions for adding new templates.
12SKILL.mdUpdated May 29, 2026
b-open-io/x-user-timeline
tools
VerifiedTrustedCommunity
Get recent tweets from an X/Twitter user. Use when user asks "what has @username posted", "recent tweets from", "user's X posts", "show timeline for", "what is @user saying". Requires X_BEARER_TOKEN.
12SKILL.mdUpdated Apr 3, 2026
b-open-io/x-user-lookup
data-ai
VerifiedTrustedCommunity
Get X/Twitter user profile by username. Use when user asks "who is @username", "get X profile", "lookup Twitter user", "find X account", "user details", "follower count for". Requires X_BEARER_TOKEN.
12SKILL.mdUpdated Apr 3, 2026
b-open-io/x-tweet-search
data-ai
VerifiedTrustedCommunity
Search recent X/Twitter posts by query. Returns RAW TWEETS (last 7 days). Use when user asks "search X for", "find tweets about", "what are people saying about", "Twitter search", "raw tweets about". For AI summaries/sentiment, use x-research instead. Requires X_BEARER_TOKEN.
12SKILL.mdUpdated Apr 3, 2026