Loop On Ci
- 1.3k installs
- 2.5k repo stars
- Updated August 5, 2026
- cursor/plugins
loop-on-ci is a Cursor agent skill that monitors GitHub pull request checks with `gh pr checks` and iterates on CI failures until all required checks pass or a retry limit is hit.
About
loop-on-ci is a Cursor plugin skill for developers who need pull request CI to go green without manual retry loops. The skill resolves the PR for the current branch, reads the full PR-attached check set via `gh pr checks` (not just GitHub Actions runs from `gh run list`), diagnoses existing failures first, then watches pending checks with `gh pr checks --watch --fail-fast`. After each fix and push, it re-inspects the entire check set and repeats until every required check passes or a configured limit stops the loop. Reach for loop-on-ci when a branch or PR keeps failing mixed CI providers—required status checks, Actions, and third-party apps—and you want an agent-driven fix-and-verify cycle instead of babysitting the Checks tab.
- Automatically detects and retries failed CI jobs in Cursor
- Configurable retry limits and backoff strategies
- Reduces manual intervention on flaky or transient CI failures
- Works with GitHub Actions, GitLab CI, and CircleCI
- Integrates directly into Cursor's agent workflow
Loop On Ci by the numbers
- 1,336 all-time installs (skills.sh)
- +203 installs in the week ending Aug 5, 2026 (Skillselion tracking)
- Ranked #231 of 2,715 Automation & Workflows skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/cursor/plugins --skill loop-on-ciAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1.3k |
|---|---|
| repo stars | ★ 2.5k |
| Last updated | August 5, 2026 |
| Repository | cursor/plugins ↗ |
How do you auto-retry failed PR CI checks?
Automatically rerun failed CI jobs until they pass or hit a limit, eliminating manual retry loops.
Who is it for?
Developers on active pull requests with flaky or multi-provider CI who already use the GitHub CLI locally.
Skip if: Developers fixing compile-only slowness or local test suites without GitHub PR checks attached to the branch.
When should I use this skill?
A branch or pull request has failing or pending required checks and the user wants automated watch-fix-retry until green.
What you get
Green required PR checks, failure diagnoses, and fix commits pushed to the branch.
- Green PR check status
- CI failure diagnosis notes
- Fix commits on the branch
By the numbers
- Uses `gh pr checks --watch --fail-fast` for pending check monitoring
Files
Loop on CI
Trigger
Need to watch a branch or pull request and iterate on CI failures until all required checks are green.
Use gh pr checks as the source of truth. It includes all PR-attached checks, while gh run list only covers GitHub Actions.
Workflow
1. Resolve the PR for the current branch. 2. Inspect current PR checks before waiting. 3. If checks already failed, diagnose those failures first. 4. If checks are pending, watch with gh pr checks --watch --fail-fast. 5. After each push, re-check the full PR check set and repeat until green.
Commands
# Resolve the active PR
gh pr view --json number,url,headRefName
# Inspect all attached checks
gh pr checks --json name,bucket,state,workflow,link
# Watch pending checks and fail fast
gh pr checks --watch --fail-fast
# GitHub Actions logs, when the failing check links to a GHA run
gh run view <run-id> --log-failedGuardrails
- Keep each fix scoped to a single failure cause when possible.
- Do not bypass hooks (
--no-verify) to force progress. - If the failure is clearly unrelated to the PR and appears fixed on main, merge latest main instead of bloating the PR with unrelated fixes.
- If failures are flaky, retry once and report flake evidence.
- Re-run
gh pr checks --json name,bucket,state,workflow,linkafter every push; the check set can change.
Output
- Current CI status
- Failure summary and fixes applied
- PR URL once checks are green
Related skills
Agent BrowserGive their coding agent reliable, high-fidelity control over any website or Electron desktop app.591k39.6k
Lark ApprovalLet their AI coding agent create, read, update, and approve items in Lark (Feishu) approval workflows without leaving the coding environment.494kLark EventHandle Feishu/Lark bot events, webhooks, and subscription callbacks in agent-driven backend code.493kLark Workflow Meeting SummaryAutomatically generate structured meeting summaries and action items from Lark/Feishu calls without manual note-taking.492kLark Workflow Standup ReportAutomatically generate and post daily standup reports in Lark/Feishu from their workflow and activity data.492k
Twitter AutomationAutomate X/Twitter posts, scheduling, and engagement via X API integration441k669How it compares
Pick loop-on-ci when PR-attached status checks span multiple providers; use Actions-only tooling when every required check lives inside GitHub Actions runs.
FAQ
Why does loop-on-ci use gh pr checks?
loop-on-ci uses `gh pr checks` because it lists every check attached to a pull request, including third-party status apps. `gh run list` only covers GitHub Actions workflows, so it can miss required checks that block merge.
When should loop-on-ci diagnose before watching?
loop-on-ci inspects current PR checks before waiting when failures already exist, so the agent fixes known breakages first. Pending checks are then watched with `gh pr checks --watch --fail-fast` to catch new failures quickly.
What happens after each push in loop-on-ci?
loop-on-ci re-resolves the pull request and re-reads the full check set after every push. The loop continues diagnosing failures and watching pending runs until all required checks pass or a retry limit is reached.