ci

Monitor GitHub Actions runs and diagnose red CI jobs after pushes.

Updated Aug 22, 2026
One-click install
npx skills add https://github.com/Bascht74/videopodcast-magic --skill ci-bascht74
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: ci
Source: https://github.com/Bascht74/videopodcast-magic/tree/main/.claude/skills/ci
Command: npx skills add https://github.com/Bascht74/videopodcast-magic --skill ci-bascht74

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? After pushing a commit, nothing tells you when the CI run finishes, and polling wastes rounds or builds repairs on top of already-red states. This Skill defines how to wait for the builder's verdict, distinguish machine failures from real code faults, and handle merges, branch deletion, and test timing data safely. ## Core Features & Use Cases - Background CI waiting: Runs tests/await_ci.sh as a harness-tracked background command that finds the run for HEAD and returns every job's verdict when it exits. - Failure triage: Decides whether a red job is the machine (missing tool, setup-step failure, runner-image sorting) or the code, then picks the smallest correct rerun (gh run rerun --job, --failed, or full) without pushing empty commits. - Post-green maintenance: Refreshes tests/state/longest via builder_times.sh, retargets stacked pull requests before deleting branches, and verifies merges before deletion. - Use Case: You pushed a commit and one of six matrix jobs (ubuntu/macos/windows on two Python versions) came back red. Use this Skill to wait for the full run, name the failed step, rule out flake causes, and rerun only the failed job before tagging a release. ## Quick Start After pushing a commit, run cd tests && bash await_ci.sh as a background command and wait for its verdict before doing anything else.

Frequently Asked Questions about ci

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I wait for a GitHub Actions run to finish after pushing?▼

Run tests/await_ci.sh as a background command tracked by the harness rather than a detached shell process. It locates the run belonging to HEAD, blocks until the run ends, and returns the verdict of every job when it exits.

How to tell if a CI failure is the runner or my code?▼

Name the failed step first: setup-step failures and missing tools like ffmpeg or PySide6 indicate the machine, while suite-step failures indicate code. Failures sorting by runner image rather than platform, or hangs far past other jobs, also point to the machine.

Should I push an empty commit to retry a failed CI run?▼

No. Use gh run rerun with --job, --failed, or bare rerun to repeat the same commit, keeping the evidence tied to the state being tagged. A pushed commit changes the state and kills the run already in progress.

Why did deleting a merged branch close my other pull request?▼

GitHub closes stacked pull requests whose base branch is deleted, and closed pull requests cannot be reopened or retargeted. Before deleting, retarget every open pull request standing on that branch with gh pr edit --base main.

When is a single green rerun enough before a release?▼

Never on its own. A rerun answers only for that one job on that state, so after reruns carry a run to green, let one whole run pass on a single state before tagging. Six green jobs collected over multiple attempts is not valid release evidence.