CI Speedup: Faster Pipelines, Same Checks

What it does

Makes slow CI pipelines and test suites faster with evidence. It times jobs, steps and tests from real runs, finds the critical path, fixes the biggest costs first (wasted runs, missing caches, serial jobs, slow tests), and compares time before and after on the same commit, with the same tests still running and passing.

Why it exists

Developers wait on CI dozens of times a day, so minutes there cost more than almost anywhere else. Tweaking whatever job looks heavy usually misses the real cost, and speedups that drop checks or retry flaky tests just move the problem. Only time on the critical path changes how long people wait.

How it works

1. Agrees on the metric, usually time from push to green on a pull request, measured as a median of runs.
2. Gets per-job, per-step and per-test timings using a bundled guide for GitHub Actions, GitLab CI, CircleCI, Jenkins, pytest, Jest, Go and JUnit, and finds the critical path.
3. Fixes in leverage order: skip unneeded work, cache dependencies and builds, parallelize the critical path, speed up slow tests, then slimmer images. A bundled lever catalog includes ready config snippets.
4. Never drops required checks, hides failures behind a cache, or adds blind retries.
5. Re-measures on the same commit and confirms the same tests still ran and passed; anything it couldn't measure is labelled an estimate.

What you get

Time to green before and after, a per-job and per-test table marked by critical path, each change with its measured saving and diff, and what was skipped and why.

When not to use it

Designing a CI pipeline from scratch, or making flaky tests pass by retrying them.

See it in action

Request:

Use the ci-speedup skill on this repo. Our GitHub Actions CI takes about 12 minutes per pull request, and the test suite is slow locally too. Make it faster without dropping any checks.

Result: Test suite 8.85 s → 0.43 s with the same 17 tests passing: fixed sleeps replaced by waiting on the queue, and a 40,000-row fixture loaded once per session instead of per test. The workflow now runs lint, test and build in parallel with pip caching and superseded-run cancellation, keeping every check. CI savings were labelled as estimates because no run history was available. The complete, unedited output, the inputs, and the before/after files are in examples/ci-speedup.

Known limitations

• Measuring real pipeline time needs CI run history (gh CLI or API access); without it, CI savings are estimates from the config.
• Test-level speedups that share fixtures assume tests don't depend on each other's state; it checks this, but review the fixture changes.
• It won't drop matrix entries or required checks to save time; it lists those as options for you to decide.

FAQ

Will it remove tests or checks to go faster? No. It keeps every required check and confirms the same tests still run and pass. Dropping a matrix entry is listed as your decision, not made for you.

Does it need access to my CI? Run history makes the before/after real. Without it, it measures the test suite locally and labels CI-level savings as estimates.

What about flaky tests? It fixes or flags them. It doesn't add automatic retries, because retries hide real failures.

Compatibility

Works with any agent that supports the SKILL.md standard. The demo was run with Claude Code (claude-sonnet-5-5) on a Python project with GitHub Actions. Covers GitHub Actions and GitLab CI configs, and pytest, Jest, Go and JUnit test suites. Reading CI run history needs the gh CLI or API access; otherwise it measures locally and labels CI figures as estimates.

Open source

Part of claude-rigor-skills: 33 MIT-licensed skills that make AI show its work. Documentation: https://github.com/hemapriyan-rk/claude-rigor-skills/tree/main/skills/ci-speedup