agentsclimarketplace

Ciloop

Skill BiswaViraj/agent-skills/plugins/agent-workflows/skills/ciloop

Use when CI is failing on a branch/PR and the user wants it driven back to green — "fix the failing CI", "CI is red, sort it out", "make the checks pass", "loop until CI is green". Pulls the real error from the failing GitHub Actions logs, reproduces it locally, fixes the confident failures, pushes once, and re-watches until green. The red-CI twin of reviewloop.From its SKILL.md

Install
npx -y skills add BiswaViraj/agent-skills --skill ciloop

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its file declares

Copied from the file, not written here

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

5.7 KB, ~1.4k tokens by cl100k_base, as published. Nobody here has run it

Ciloop

Drive a failing CI run to green. Pull the real error from the logs, reproduce it locally, fix the failures you're confident about, push once, and confirm — looping until green.

Core principle: CI is slow and costs minutes, so don't use it as your edit-test loop. Reproduce the failure locally, fix until local is green, then push once. And don't flail: fix what you can diagnose with confidence; for failures you can't (flaky, infra, secrets, ambiguous logic), stop and hand back rather than guess. Loop the fixable; hand back the judgment calls.

When to use

  • A push/PR has red checks and you want them green without babysitting each run.
  • "Fix the failing CI", "make the checks pass", "CI is red, loop until it's clean".

When NOT to use: You only want to read why CI failed without fixing → just gh run view --log-failed. The failures are all infra/deploy/flaky (nothing to fix in code) → ciloop will just hand those back.

Classify every failure first

CategoryExamplesAction
Confident-fixlint, format/prettier, type errors (tsc), clear test/assertion failures, missing import, obvious compile errorreproduce locally → fix → loop
Hand-backflaky/non-deterministic tests, infra/network timeouts, missing secrets/credentials, deploy/release steps, ambiguous logic failures you can't pin downdon't touch — record the real error + why, report at the end

A step that can't run locally (needs live services, secrets, a built artifact) is hand-back, not a guess. Never push a speculative fix for something you couldn't reproduce.

Inputs

  • branch / PR (optional): default = current branch.
  • --max-iterations N (optional, default 5): cap on the fix→push→watch loop.

The loop

0. Find the red run

BRANCH=$(git rev-parse --abbrev-ref HEAD)
HEAD_SHA=$(git rev-parse HEAD)
gh run list --branch "$BRANCH" --limit 5 \
  --json databaseId,headSha,status,conclusion,workflowName

Pick the most recent run for HEAD_SHA. If it's success → report "already green" and stop. If still in_progress → wait (gh run watch). See references/gh-ci.md.

1. Pull the real failures

gh run view <run-id> --json jobs \
  --jq '.jobs[] | select(.conclusion=="failure") | {name, steps: [.steps[] | select(.conclusion=="failure") | .name]}'
gh run view <run-id> --log-failed

Read the actual error from --log-failed — not just "job X failed". Find the line that caused it.

2. Classify each failing job (table above)

Split into fix and hand-back. If there are zero fixable failures, skip to the report.

3. Reproduce + fix locally

For each fixable job, map it to its local command by reading the workflow that ran it:

# find the failed step's exact command
cat .github/workflows/*.y*ml   # locate the failing job → its `run:` step

Run that exact command locally (e.g. pnpm lint, pnpm typecheck, pnpm test <file>), read the error in context, fix the root cause, and re-run the command until it passes locally. Repeat per fixable job. (If the YAML is a composite/opaque action, fall back to the obvious local command for the job's purpose — but if you can't reproduce it, treat it as hand-back.)

4. Push once

Only after every fixable job is green locally:

git add -A
git commit -m "fix CI: <what failed> (ciloop iteration N)"
git push

One push per iteration — not one per fix.

5. Confirm the re-run

git rev-parse HEAD   # new sha — watch THIS run, not the stale one
gh run watch <new-run-id> --exit-status

Guard against acting on a stale run: only evaluate the run whose headSha matches the new local HEAD.

6. Exit conditions

  • New run is green → done.
  • Still red with fixable failures → back to step 1, until --max-iterations.
  • Only hand-back failures remain → stop and report (don't burn iterations on what you won't fix).

Common mistakes

MistakeFix
Using CI as the edit-test loop (push every fix)Reproduce locally, fix to local-green, push once.
Pushing a fix you couldn't reproduce locallyIf it won't run locally, it's hand-back — don't guess.
Reading "job failed" but not the actual errorAlways --log-failed and find the causing line.
Watching the old run after pushingRe-resolve the run id for the new HEAD sha before watching.
Looping forever on a flaky/infra failureClassify it hand-back; stop and report instead.
"Fixing" a flaky test by rerunning until it passesThat's hand-back — report it; don't mask flakiness.

Report

Ciloop complete.
  Branch:      eng-522-migrate-the-voice_service
  Iterations:  2
  Fixed:       lint (3 files), typecheck (1 error), unit test auth.spec.ts
  Handed back: e2e job — flaky (timeout on external service), not a code issue
  Final CI:    green ✅

If stopped at max iterations or on hand-back failures, list each remaining failure with its real error and a suggested next step.

What ships with it: 1 file

2.6 KB alongside SKILL.md

references/

Keep looking

Skills are one crate of 326,499. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.