OpenAI's CI playbook (for GitHub Actions)

Install the ci-speedup skill (npx skills add starslingdev/skills --skill ci-speedup) and run it on this repo. Summarize what it finds, starting with the slowest check, with the saving where the report gives one, and ask me which to apply. Show me the diff and open a PR rather than applying it blindly.

Diagnose why a GitHub Actions job in this repository fails and then passes on an identical rerun, without changing anything yet. First pull the job's run history with the GitHub Actions REST API (`GET /repos/{owner}/{repo}/actions/runs`, filtered by `status`) to confirm a real failure rate rather than one unlucky run. Then check, in this order: (1) fixed-length waits in the failing test's source (`page.waitForTimeout`, `cy.wait(ms)`, raw `sleep()`); (2) a `sleep N` step standing in for a container healthcheck in the same workflow; (3) a `vitest` invocation with no `run`/`--run` flag on the failing job; (4) whether that job has `timeout-minutes` set at all; (5) whether the check that actually went red is in the repo's required-status-checks list. Stop at the first cause you confirm, report which one it is and the exact evidence (grep match, API result, or log line), and do not edit any workflow, test, or config file until you report back.

Fetch OPT87 "Tests Wait on a Slow Dependency They Do Not Verify" from https://raw.githubusercontent.com/starslingdev/skills/main/skills/ci-speedup/references/optimization-patterns.md and check this repo against it yourself. Find the slowest test job gating the merge and read its step timings over the last 20 runs of its workflow with the GitHub CLI (gh run list, then gh run view --json jobs for each run). Run that suite locally with its runner's slowest-tests report (pytest --durations, a verbose vitest reporter, or cargo nextest's slow-test output) and list the slowest test files. It applies only when a slow file's time goes to a call outside the code under test (a network API, a model endpoint, a cloud service, a resolver or lookup service) that the test does not exist to verify. If it applies, follow the entry's recipe: replace that call with the repo's existing mocking or fixture tooling, keep every test and every assertion, and keep one job that still exercises the real dependency, nightly or after merge. Never mock the thing a test exists to verify, and never delete, skip or weaken a test to make it faster. Report each suite's runtime before and after on the same machine. If nothing qualifies, tell me in one line why. Show me the diff and open a PR rather than applying it blindly.

Fetch OPT85 "Tests Run in Many Processes Instead of One" from https://raw.githubusercontent.com/starslingdev/skills/main/skills/ci-speedup/references/optimization-patterns.md and check this repo against it yourself. Find the slowest test job gating the merge and read its step timings over the last 20 runs of its workflow with the GitHub CLI (gh run list, then gh run view --json jobs for each run). It applies when that suite's time goes to starting processes: tests that launch a subprocess, interpreter or CLI for each case, or a Rust crate with many integration-test binaries under tests/, each linked and started on its own. Measure it before changing anything: time one case through a subprocess against the same check called in-process, or count the test binaries and time the suite. If it applies, follow the entry's recipe: call the code in-process wherever the test does not exist to verify process behavior, or merge the integration tests into a single test binary, keeping every test case and assertion. Keep at least one test that runs the real process end to end. Report the suite's runtime before and after on the same machine. If nothing qualifies, tell me in one line why. Show me the diff and open a PR rather than applying it blindly.

Fetch OPT86 "CI Compiles a Dependency That Ships Prebuilt" from https://raw.githubusercontent.com/starslingdev/skills/main/skills/ci-speedup/references/optimization-patterns.md and check this repo against it yourself. Read the install steps' logs from the last 20 runs of each test workflow with the GitHub CLI (gh run list, then gh run view --log) and look for source builds: lines such as "Building wheel for", "Running setup.py", native extension compiles, node-gyp rebuilds, or compiling a tool that publishes a binary release. It applies only when a dependency compiles from source on a runner and a version of it publishes a prebuilt package for that runner's platform and language version. If it applies, follow the entry's recipe: select a version that ships prebuilt packages for every interpreter in the matrix, make the installer refuse silent source builds where it supports that (pip --only-binary, or uv's no-build setting) so a future source build fails loudly, and restore the dependency cache if it is disabled. Tell me before changing any dependency's major version, and leave alone any job that exists to test building from source. If no install step compiles from source, tell me in one line why. Show me the diff and open a PR rather than applying it blindly.

Fetch OPT24 "Long Test Job Without Sharding" and OPT25 "Shard Imbalance" from https://raw.githubusercontent.com/starslingdev/skills/main/skills/ci-speedup/references/optimization-patterns.md. If the slowest test job is not sharded, follow OPT24. If it is, get per-file runtimes (the test runner's own timing output, or the logs of the last 20 runs, read with gh run view --log) and list shard durations. If one shard is consistently longer because of a few slow files, split those files along their existing describe blocks before adding shards. If shards are uneven without one dominant file, use timing-based splitting only where the runner supports it (OPT25 names pytest-split and nextest timing data; Vitest's --shard splits by file and has no timing mode). Propose a higher shard count only once shards are balanced. Show me the diff and open a PR rather than applying it blindly.

Fetch OPT89 "The Slowest Platform Compiles Its Own Tests" and OPT14 "Repeated Checkout/Setup Without Artifact Handoff" from https://raw.githubusercontent.com/starslingdev/skills/main/skills/ci-speedup/references/optimization-patterns.md and check this repo against them yourself. For each sharded or matrix test job, read the step timings of the last 20 runs of its workflow with the GitHub CLI (gh run list, then gh run view --json jobs for each run). OPT14 applies when every shard or leg compiles the same build before running its slice of the tests: follow its recipe, adding one job that builds once and uploads the output the tests need as an artifact (for Rust, a cargo nextest archive), and have each shard download it and run its slice. OPT89 applies when the slowest platform leg spends most of its time compiling: follow its recipe, building that platform's test binaries on a faster runner that can cross-compile for it and running them natively on the slow platform, and keep a fully native run after merge. Scope artifacts to the run and commit and give them a short retention. If neither applies, tell me in one line why. Show me the diff and open a PR rather than applying it blindly.

Fetch OPT88 "Test Concurrency Is a Guess, Not a Measurement" from https://raw.githubusercontent.com/starslingdev/skills/main/skills/ci-speedup/references/optimization-patterns.md and check this repo against it yourself. Find the slowest test job gating the merge, read its step timings over the last 20 runs of its workflow with the GitHub CLI (gh run list, then gh run view --json jobs for each run), and find where it sets test parallelism (pytest-xdist -n, Jest --maxWorkers, Vitest pool options, cargo nextest --test-threads, Bazel --local_test_jobs or --jobs), or that it sets none. If the entry applies, follow its recipe: on a branch, run the same commit on the same runner label at the current setting and at two or three others around the runner's core count, at least three runs each, and compare the medians. Keep tests that share state on a serial lane. The same tests must pass at every setting you compare, and a setting that runs out of memory on any run does not count as faster. Never change which tests run. Show me the timings and wait for me before changing the default. If the setting already matches a measured best, tell me in one line why. Show me the diff and open a PR rather than applying it blindly.

Fetch OPT79 "A Cache That Costs More Than It Saves" from https://raw.githubusercontent.com/starslingdev/skills/main/skills/ci-speedup/references/optimization-patterns.md and check this repo against it yourself. For each actions/cache step, read the last 20 runs of its workflow with the GitHub CLI (gh run list, then gh run view --json jobs for each run, and gh run view --log for the cache steps) and compare the time spent restoring (Run actions/cache) with the time spent saving (Post Run actions/cache), and how often the restore finds a cache ("Cache restored" against "Cache not found" in the logs). It applies only when restore plus install plus save on cache hits costs more than install alone on misses, weighted by how often the cache hits. If it applies, follow the entry's recipe in its order, and remove the cache only when the measurements still show it costs more than it saves. Never remove the step the cache feeds. If no cache qualifies, keep it and tell me in one line why. Show me the diff and open a PR rather than applying it blindly.

Fetch OPT81 "The Same Job Is Measurably Faster on Another Runner" from https://raw.githubusercontent.com/starslingdev/skills/main/skills/ci-speedup/references/optimization-patterns.md and check this repo against it yourself. First apply any cheaper fix on the slowest job (setup, caching, test isolation). Then read the last 20 runs of the workflow that holds that job with the GitHub CLI (gh run list, then gh run view --json jobs for each run) and list which runner label each run of the job used and how long it took. If the same job ran on two runner classes with the same operating system and processor architecture, over the same period and with the same steps, and the entry's sample and gap conditions hold, first find out why some runs use the slower label (a fork pull request, an event or a matrix condition can select it on purpose), as its recipe says; if nothing requires it, move the job to the faster label, keeping every step it runs. If instead the job runs on one standard GitHub-hosted label, its slowest step is build or test work, and nothing cheaper is left, change no runner: show me the job and how to benchmark a larger runner beside its current one on a branch, and wait until I have run it and compared the medians. Otherwise tell me in one line why it does not apply. Note: StarSling, who publish this catalog, sell StarSling Runners, one of the runners worth benchmarking. Show me the diff and open a PR rather than applying it blindly.