ci-pipelinelisted

Watches every CI run a gitops action kicks off — push, PR, merge, tag or dispatch — on the checked-out repo/branch. Load it automatically, without being asked, the moment a push, PR or merge happens in this session, including one you just made; finishing a push is not finishing the task. Monitors all active runs; on a failure it reads that job's real logs, prints what broke, then re-runs once for a real infra blip (OOM, timeout, rate limit), or makes the smallest safe fix with a regression test, pushes, and comments on the PR. For a larger problem it stops and lays out options with tradeoffs, recommending a stacked PR. Never guesses. Never skips, disables or loosens a check, or pushes to trunk. `/ci-pipeline init` records which checks gate a merge and how to run each locally. Also use on /ci-pipeline, /devops, /pr-pipeline-watch, "set up ci-pipeline", any question about CI, a build or a red check, or a bare "did that pass?". Not for feature work or releases (/release). Needs `gh` — Claude Code only.
dawg-io/claude-skills · ★ 0 · DevOps & Infrastructure · score 72

Install: claude install-skill dawg-io/claude-skills

# ci-pipeline Watches the CI pipeline for the repo and commit you're working on — after a push, an opened or merged pull request, a tag, or any other gitops action that kicks off a run — figures out why a check failed, fixes the actual cause, and reports back. This skill has real side effects: it re-runs jobs, cancels runs, commits, pushes, and comments on PRs. Move deliberately in Phase 5, which is where "am I fixing the bug or hiding it" gets decided. What this repo's CI actually *is* — which checks exist, which ones block a merge, how to reproduce each one locally, which are safe to re-run — comes from **`.claude/ci-pipeline.yml` in the repo being watched**, written by `/ci-pipeline init`. Without it the skill still runs, deriving all of that from the repo on every single wake — slower, and worse at exactly the moment a pipeline is red. Either way this skill hardcodes nothing. The hard rules, restated up front because they're the ones that erode under "just get it green" pressure: 1. **Root cause, not symptom.** Trace the failure back to what is actually broken. 2. **No cheap fixes.** If the pipeline goes green but the underlying bug is still there, that is a failure of this skill, not a success. 3. **No unrelated changes.** Fix the failing check. Nothing else. 4. **Never push to the trunk branch.** A fix always lands on a topic branch via a PR. 5. **Never claim a command ran that didn't run.** "Not run — <reason>" is a fine answer. A fabricated pass is not. 6. *