ci-score
Grade your GitHub Actions configuration against CI best practices and get a ranked fix for every gap
ci-score is a free, open-source, MIT-licensed agent skill that runs on your machine, grades a repository's GitHub Actions configuration against CI best practices, and hands your coding agent a concrete fix for every gap. It works independently of StarSling Runners and does not require the StarSling GitHub App.
See the ci-score overview for a quick introduction before following the operational guide below.
ci-score grades configuration adherence, not speed — a fast repo can hold a low score. For a measured audit of what actually makes your CI slow, use ci-speedup. Both are local, on-demand skills; StarSling optimization PRs are a separate paid, hosted service.
Before you start
You need:
- A full local checkout of the repository you want to score. The score reads workflow YAML, local composite actions, and repo-root build-tool configs, so a partial view understates your setup.
- Python 3.9 or newer and PyYAML.
- Node.js and npm to install or invoke the skill with
npx.
No network access is used during scoring — everything reads the local tree, and nothing is sent to StarSling.
Install and run
Install the skill with Vercel's Skills CLI:
npx skills add starslingdev/skillsThe CLI lets you select the coding agent and whether to install the skill for the current project or globally. It supports a long list of coding agents, including Claude Code, Codex, Cursor, and OpenCode.
In a repository, invoke the installed skill from your coding agent:
/ci-scoreThe skill confirms the repository before it starts scoring. To use it without installing, ask your coding agent to run this command and follow the generated instructions:
npx skills use "https://github.com/starslingdev/skills" --skill "ci-score"What the score measures
The CI Score is a pass/fail rubric of eleven configuration facts, each verifiable in your own workflow files in under a minute:
- Dependency caching — a cache action or a
setup-*cache input is configured - Build caching — a build-tool cache (Turbo, Nx, Gradle, sccache, Bazel) is configured
- Shallow checkout — no PR-gating checkout pulls full history with
fetch-depth: 0 - Test sharding / matrix — a test job runs a matrix or a shard-like axis
- Change-scoped builds — CI scopes work to what changed
- Concurrency groups — a PR-triggered workflow declares a concurrency group
- Superseded runs cancelled — that concurrency group sets
cancel-in-progress - Path filters — a PR-triggered workflow scopes itself with
paths/paths-ignore - Job timeouts — jobs set
timeout-minutesinstead of GitHub's 360-minute default - Scoped OIDC id-token —
id-token: writeis granted per job, never workflow-wide - Pinned action SHAs — at least 95% of remote action references are pinned to a commit SHA
A check whose subject doesn't exist in your repo is not applicable and leaves the denominator. Your score is checks passed over checks applicable. The report ranks one fix per failed check by impact × risk, each with a fix recipe and a paste-able agent prompt.
Two caveats the report repeats beside the score: it measures adherence, not speed, and it is not a security audit — exactly two of the eleven checks (action pinning and OIDC token scoping) happen to be security-related.
ci-score versus ci-speedup
| ci-score | ci-speedup | |
|---|---|---|
| Question | Does my CI config follow best practices? | What actually makes my CI slow? |
| Input | Your local checkout's workflow YAML and configs | Real run history sampled over the gh API |
| Output | A score plus one ranked fix per failed check | A measured root-cause report of the merge-gating long pole |
| Requires | A full checkout, Python, and PyYAML | The above plus an authenticated gh CLI |
| Runtime | Seconds, fully offline | Minutes, scaling with repo size |
Both are free, open source, run on your machine, and send nothing to StarSling.