cilisted

What it is — a standard for writing CI that stays green for the right reasons: GitHub Actions conventions, pinned toolchains instead of registry-fate lookups, weekly cascades that land dependency bumps and vendored checkers only on green, external-fate jobs kept off pull requests, and falsifiable checks proven able to fail. Use when writing, reviewing or checking any CI workflow, when pushing to a repository that has CI and after the push (ci.sh watch follows the runs to a verdict), when asked whether CI passed or why it went red, when adding badges, setting up dependency auto-updates, deciding what gates a PR, debugging a CI failure that appeared without a code change, or starting CI for a new repo. Triggers: CI, GitHub Actions, workflow, pipeline, badge, cron, dependabot, vendor-sync, vendor.lock, vendored file, push, did CI pass, check CI, напиши CI, проверь CI, посмотри пайплайн, запушь, прошёл ли CI, почему упал CI, добавь workflow, бейджи, обнови зависимости в CI.
rokokol/ci-skill · ★ 0 · AI & Automation · score 75

Install: claude install-skill rokokol/ci-skill

# ci CI earns its keep only while a green run means something. Everything here serves that one property: a check that cannot fail proves nothing, a job that fails without a code change teaches nothing, and a badge nobody trusts might as well not render. The references carry the reasoning; `templates/` carries copyable GitHub Actions files with `EXAMPLE` markers for the repo-specific parts ## The rules - **A job is either a gate or a detector — never both.** Repository-only checks gate pull requests; checks that depend on external uptime or drift run on the default branch, on a schedule and by hand, never on pull requests. See [references/badges.md](references/badges.md) - **Every tool a job runs is pinned.** Actions use version pins and toolchains come from the repository's lockfile, never a live registry lookup; `templates/check-pins.sh` enforces the distinction. See [references/pinning.md](references/pinning.md) - **The build workflow declares `workflow_call` with a `ref` input**, so automation (dependency bumps, drift bots) verifies branches by running *the real workflow*, not a copy of its commands that drifts apart from it. See [references/workflows.md](references/workflows.md) - **Dependency updates land themselves, but only on green.** A scheduled cascade bumps a temporary branch, verifies it through the real build workflow, fast-forwards on green and leaves red for inspection. See [references/bump-cascade.md](references/bump-cascade.md) - **A file that travels is v