Linear's CI playbook, ready to hand to your agent

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.

Fetch OPT84 "A Slow Step on the Long Pole Runs a Tool That Has a Native Drop-in" 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 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 only if a step there runs tsc --noEmit (directly or through a package.json script) for at least 20 seconds and the repo is not already on TypeScript 7; a tsc that emits files does not qualify. If it applies, follow the entry's TypeScript 7 row (typescript@^7; the command is still tsc), read the TypeScript 7.0 announcement it links, and promise no speedup. Benchmark both versions on the same commit and runner class, diff their output, and keep the old type-check beside the new one until a sampled run matches. Anything that calls the compiler API (typescript-eslint type-aware rules, ts-loader) keeps the side-by-side TypeScript 6 alias, and 7.0's new defaults can surface new errors; list them for me. Never skip or narrow the type-check to make it fit. If no type-check step on the slowest path qualifies, tell me in one line why, and stop. Show me the diff and open a PR rather than applying it blindly.

Fetch OPT82 "Lint Builds the Whole Type Graph" from https://raw.githubusercontent.com/starslingdev/skills/main/skills/ci-speedup/references/optimization-patterns.md and follow its recipe, including the benchmark it runs first and its rule-by-rule ledger. Read this repo's ESLint config and list every rule that needs type information (parserOptions.project / projectService, or typescript-eslint's type-checked sets). For each, decide: rewrite it as an AST-only rule, or move it into a separate type-aware lint job. That job may check changed files only if a merge queue or another required pass still runs it over the whole tree; otherwise it stays a required check over the whole tree. Never disable a rule to make lint faster. Show me the diff and open a PR rather than applying it blindly.

Fetch OPT84 "A Slow Step on the Long Pole Runs a Tool That Has a Native Drop-in" and OPT82 "Lint Builds the Whole Type Graph" from https://raw.githubusercontent.com/starslingdev/skills/main/skills/ci-speedup/references/optimization-patterns.md and check this repo against them yourself. Find the slowest 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). OPT84's ESLint to oxlint row applies only if a step there runs eslint (directly or through a package.json script) for at least 20 seconds and the repo does not already run oxlint. If that lint step also qualifies for OPT82, do the OPT82 work first. Read the ESLint config: if it has custom local rules, the tailwindcss plugin, a framework plugin or any other plugin oxlint does not carry, a react-hooks/exhaustive-deps rule, type-aware rules, or a shared config you cannot follow, use the entry's run-both shape: run oxlint across the tree and keep ESLint scoped to the rules oxlint lacks. Follow the oxlint migration guide the entry links, and promise no speedup. Never drop, narrow or disable a rule, plugin or file set to make the swap fit. Migrate the config first, then benchmark both tools on the same commit and runner class and diff their output before removing anything. One tool per PR. If no lint step on the slowest path qualifies, tell me in one line why, and stop. Show me the diff and open a PR rather than applying it blindly.

Fetch OPT28 "Full Git History Checkout" from https://raw.githubusercontent.com/starslingdev/skills/main/skills/ci-speedup/references/optimization-patterns.md and follow its recipe. For every actions/checkout step in .github/workflows: delete the checkout only if no step in that job reads a file from it, directly or indirectly: check for a local action (uses: ./...) and open its definition, hashFiles() in a cache key, a run: that calls git or a repo script, and a gh command that relies on the current repo (it then needs --repo or GH_REPO); a missing file fails the job, so delete only when every step is accounted for; if it reads only a few paths, use sparse-checkout so only those paths are written; use a shallow depth where nothing needs history. For a diff gate that needs history but not every file's contents, use filter: blob:none with fetch-depth: 0, which fetches file contents on demand. Keep the base branch reachable for jobs that diff against it (turbo --filter=...[origin/main], nx affected, vitest --changed), and keep fetch-depth: 0 where something walks history or tags. Show me the diff and open a PR rather than applying it blindly.

Fetch OPT80 "Checkout Stalls on the Tail" from https://raw.githubusercontent.com/starslingdev/skills/main/skills/ci-speedup/references/optimization-patterns.md and check this repo against it yourself. For each job's checkout step, read its duration over the last 20 runs of the workflow with the GitHub CLI (gh run list, then gh run view --json jobs for each run). Where a few runs take far longer than the rest, read those runs' checkout logs (gh run view --log): the entry applies only when the git fetch stood still, with the same Receiving objects percentage on both sides of a pause, not when the fetch was merely slow or the checkout is simply large. If it applies, follow its recipe in its order: wrap checkout in a composite action that retries with backoff and sets GIT_HTTP_LOW_SPEED_LIMIT and GIT_HTTP_LOW_SPEED_TIME so a stalled fetch aborts instead of hanging, shipped together, never the abort without the retry. The composite action lives in this repo and is referenced by path; pin every third-party action it uses, actions/checkout included, to a full commit SHA. If no run shows a stalled fetch, tell me in one line why, and stop. Show me the diff and open a PR rather than applying it blindly.

This move is done by reading the workflows. In every job that is a required check, list the steps that only produce something for later runs (a cache save, a marker write, an artifact no later job in this run reads). Move each into a separate job that needs the test jobs and is not a required check, so the merge path no longer waits on it. Do not move anything a later job in the same run depends on, and do not use a post step: it still runs inside the required job. Then fetch OPT71 "Expensive Non-Required Check on the Critical Path" from https://raw.githubusercontent.com/starslingdev/skills/main/skills/ci-speedup/references/optimization-patterns.md and check this repo against it yourself: read the last 20 runs of each pull-request workflow with the GitHub CLI (gh run list, then gh run view --json jobs for each run) to find the slowest checks, and read the required checks (gh api repos/OWNER/REPO/rulesets and the branch protection's required_status_checks). If one of the slowest checks is not required and, once you have listed everything that consumes its result, is genuinely advisory (a comment, a preview, a non-blocking annotation), apply the least aggressive option its recipe gives. If it runs real tests or validates a build, speed it up instead of de-scoping it, and if the required checks cannot be read, de-scope nothing. If nothing qualifies, tell me in one line why. Show me the diff and open a PR rather than applying it blindly.

Fetch OPT1 "Unnecessary Tool Install" and OPT73 "Shared Sub-Step Across Critical-Path Jobs" from https://raw.githubusercontent.com/starslingdev/skills/main/skills/ci-speedup/references/optimization-patterns.md and check this repo against them yourself. Handle each on its own. OPT1: read the workflows and delete installs of tools a job never uses; if a shared setup action does the install, make it conditional or split the action. OPT73: read step timings over the last 20 runs of each pull-request workflow with the GitHub CLI (gh run list, then gh run view --json jobs for each run) and look for a setup step (apt-get, a toolchain download, a dependency install) that recurs with real cost in two or more of the jobs that finish near the slowest one. If one does, follow its recipe: make that step cheap in every job that runs it, choosing between a cache keyed on the step's real inputs and a prebuilt base image, and never move it into one upstream job the others need. If you propose a container image, first list what changes for services, Docker steps and paths, before switching any job. If neither applies, tell me in one line why. Show me the diff and open a PR rather than applying it blindly.

Fetch OPT54 "Full-Repo `pnpm -r` Where Package Filters Are Possible" from https://raw.githubusercontent.com/starslingdev/skills/main/skills/ci-speedup/references/optimization-patterns.md and scope recursive pnpm commands in .github/workflows with --filter as it describes. Then apply the same idea to installs: for each job, work out which workspace packages its later steps use and install with pnpm install --frozen-lockfile --filter "<package>..." (the trailing ... includes that package's dependencies). Confirm nothing in the job imports a package outside the filter. Show me the diff and open a PR rather than applying it blindly.

Fetch OPT79 "A Cache That Costs More Than It Saves" and OPT6 "Cache Key Entropy Too High or Unstable" from https://raw.githubusercontent.com/starslingdev/skills/main/skills/ci-speedup/references/optimization-patterns.md and check this repo against them yourself. OPT79: for a job with exactly one dependency cache, read the last 20 runs of its workflow with the GitHub CLI (gh run list, then gh run view --json jobs for each run), plus the cache and dependency steps' logs (gh run view --log), and compare restore plus dependency setup on cache hits against the same steps on misses, on the same runner label. It applies only when a hit is measured slower than a miss. If it applies, work in the order its fix gives: a restore that is slow on a hit means the archive is too big, so first cache the package manager's store (for pnpm, the pnpm store) instead of node_modules, or scope the cache and the dependency step to the package this job needs (OPT54's filtered install, OPT8's key granularity), then re-measure. Remove the cache only if a filtered install is still faster than any restore, and never drop the step the cache feeds or skip it on some runs. OPT6 is a separate problem, a cache that misses: if a cache key includes github.sha, github.run_id, a date or another value that changes every run, fix the key as OPT6 says. If neither applies, keep the cache and tell me in one line why. Show me the diff and open a PR rather than applying it blindly.

No catalog pattern covers this one. Find the step in .github/workflows that prepares the test database (migration replay, seed, or a script named migrate/setup-db). Time it over the last 20 runs of its workflow with the GitHub CLI (gh run list, then gh run view --json jobs for each run). If it is a material share of the job, propose replacing replay with loading a generated schema snapshot: add a script that dumps the schema at the current migration head, commit the snapshot or generate it in a cached step, and load it in CI. Keep one job that still replays migrations end to end, so migration bugs are still caught. Show me the diff and open a PR rather than applying it blindly.

Fetch OPT77 "Repeated Fixed Setup Across Independent Small Jobs" and OPT83 "Independent Steps on the Long Pole Run One After Another" from https://raw.githubusercontent.com/starslingdev/skills/main/skills/ci-speedup/references/optimization-patterns.md and check this repo against them yourself. Read step timings over the last 20 runs of each pull-request workflow with the GitHub CLI (gh run list, then gh run view --json jobs for each run). OPT77: look for small independent jobs on the same runner label that repeat the same setup steps (checkout, setup actions, dependency install) and spend at least as long on that setup as on their own work. If such a group exists, merge only those jobs into one, run their tasks concurrently inside it (a parallel: step group), and keep the two conditions its recipe names: no job outside the group may wait on a member, and the merged job must stay shorter than the tallest job that remains. The merged job still runs every check and fails when any of them fails. OPT83: on the slowest job gating the merge, look for adjacent compute steps that each take at least 20 seconds and at least 15% of the job; if the entry's independence checklist holds for all of them, rewrite only those steps as one GitHub Actions parallel: group, and benchmark it before keeping it. If either part does not qualify, leave it alone and 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 OPT78 "Per-File Test Isolation Rebuilding Shared Module State" from https://raw.githubusercontent.com/starslingdev/skills/main/skills/ci-speedup/references/optimization-patterns.md and check this repo against it yourself; it covers vitest only. Read the logs of the slowest test job over the last 20 runs of its workflow (gh run list, then gh run view --log) and find vitest's Duration line. It applies only when import plus transform exceeds tests there, import is above 30 seconds, and the vitest config keeps isolation on (no isolate: false anywhere, no vm pool). If it applies, read the config's history first, then follow its recipe and guardrail exactly; never set isolate: false globally. Add a second vitest project with isolate: false. Files join it only through an explicit include list or a dedicated filename suffix, and only files with no module-level mutable state and no fake timers. Write teardown for any shared state they touch, enable sequence.shuffle there, and start in shadow mode (files run in both projects; the shared one is not required). If it does not apply, tell me in one line why, and stop. Show me the diff and open a PR rather than applying it blindly.

Fetch OPT73 "Shared Sub-Step Across Critical-Path Jobs", OPT54 "Full-Repo `pnpm -r` Where Package Filters Are Possible", OPT79 "A Cache That Costs More Than It Saves" and OPT25 "Shard Imbalance" from https://raw.githubusercontent.com/starslingdev/skills/main/skills/ci-speedup/references/optimization-patterns.md. For the slowest test job, 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 measure the setup prefix (checkout, dependencies, containers, migrations) against the test step. Tell me, in seconds, what each added shard costs in setup today, and check this repo against OPT73, OPT54 and OPT79 yourself to see which would shrink it; apply each only where its own conditions hold, and do those first. Propose a higher shard count only in a later PR, once the setup changes are merged and new runs show the smaller setup. Show me the diff and open a PR rather than applying it blindly.