Three great X articles in the past week on CI at agent speed 🔥 We turned them into 4 new patterns in ci-speedup, @starslingdev's open source skill that checks for 95 ways GitHub Actions can waste time (prompt below). ci-speedup finds what's slowing down your CI using your real run data and hands your coding agent a prompt to fix it. The 4 new checks: 1. Every new PR reinstalls dependencies from scratch. GitHub only lets a PR reuse a cache saved on its own branch or on main, and if CI only runs on PRs, nothing is ever saved to main (from @owengretzinger's article). 2. Jobs wait to start even though your runners are mostly idle, because something only lets one job run at a time: a single emulator, a database lock, or one concurrency group shared by every PR (from @_ethanleonard's article). 3. Your merge queue reruns the full test suite on changes the PR already tested, or your repo requires every branch to be up to date before merging, which at high PR volume means endless rebases and reruns. 4. Red runs that aren't your code: the runner disappeared, the job ran out of memory, the browser crashed, or the package registry errored, and each one reruns the whole workflow. Also new: if you skip tests for code a PR didn't touch, it now checks for the safety nets. Run everything when the lockfile or CI config changes or when it's unclear what a change affects, run the full suite after merge, and confirm your skip logic really runs the tests it should (from @o_kwasniewski's article). And every report now shows where your PRs actually spend their time, so you can see whether CI is the slow part at all. Prompt: "Run npx skills add starslingdev/skills --skill ci-speedup to install or update the ci-speedup skill."

Hack vector we're seeing in almost every customer codebase: github actions that aren't pinned to specific versions. Github actions are build steps that run in CI and in deploy workflows. There are third party actions that do all kinds of utility operations: list changed files, log in to Docker, deploy to github pages... etc. Everyone uses them. The problem is that their behavior can change. This is code that runs in your CI that can change under you at any time. It isn't versioned by your own version control. A third party can change what these actions do whenever they want. A lot of very widely used utilities are managed by solo devs on their personal github accounts: peaceiris/actions-gh-pages, dorny/paths-filter, appleboy/ssh-action. If these github accounts get taken over, the attacker can run arbitrary code within your github runners: exfiltrate your code, steal whatever secrets are in CI, even inject code changes into deploys. A lot of github workflows pin to a version, like dorny/paths-filter@v3. This is not good enough, because those version tags can be changed at any time to point to new commits. You need to pin to a specific sha, like dorny/paths-filter@0e4a8c6effa4802afeda77dc8d303f8176d7dfad. This happened last year. Attackers compromised a popular github action. (A simple util that listed files changed in a PR.) They shipped a malicious version of the github action, and then they retroactively changed version tags like "v1.0.0" to point to that compromised code. They used this to steal secrets from 23,000 repos. This is a really broad amplification vector that will take you very little effort to avoid upfront. I'm not sure if this category of vuln even has a name, but it's a ticking timebomb. What we're doing for our own code: 1. Switch all github actions to pinned shas 2. Add a lint rule that makes sure all github workflows use pinned shas, not any other kind of version tag Both of these are oneshot-able in your agent of choice.

A new GitHub Actions runner launches every week now. But getting faster runners is just one part of what the best engineering teams do to speed up their CI. Introducing CI Playbooks ▶️ an agent-friendly library of 253 GitHub Actions optimizations from companies running software factories. We analyzed 416 pull requests and commits, and 182 blog posts, talks, and podcasts from ten companies: 1. Anthropic: CI job volume grew 25x in six months as Claude came to write 80% of its code 2. DoorDash: build and test cut from 22 minutes to 6 3. Linear: jobs 34% faster while test suites almost quadrupled 4. Mastra: 29m 56s to 5m 06s p95 on StarSling runners 5. OpenAI: about 30 CI PRs took median CI from about 10 minutes to 4.5 6. Ramp: its coding agent accounts for 74% of merged PRs 7. Shopify: an agent running experiments made the Polaris build 65% faster 8. Spotify: deployer image build went from 2h28m to about 17 minutes 9. Stripe: runs about 5% of its full Ruby test suite per build 10. Uber: CI resource usage down 53%, wait times down 37% Some of these companies aren't using GitHub Actions as their CI engine internally so we translated all the optimizations they've talked about or made publicly in their repos, into their GHA equivalents. Every technique comes with its original source and a prompt your coding agent can run on your repo. Add .md to any playbook URL for the markdown version, or just hand this URL to your agent: There's tons to dig into here, I'm going to highlight some of the findings I found most interesting 🧵

Today we shipped sling, an agent-first CLI for your GitHub Actions 💫 Right now, if you ask your agent why a CI job failed, it goes and pulls the entire set of GHA logs and eats up your context window. 🪵 > sling why @starslingdev computes the run's logs and metadata, along with the evidence lines it matched to tell you why a run failed If you want to know what your GHA usage is, you have to go to the GH UI and click around to find it. 💸 > sling bill tells you how many minutes, how much you're spending, and across which runner labels Trying to understand what your slowest job is? You'll need to hunt around the GHA UI and even then you only get an average. 📊 > sling top and sling usage tell you runner minutes and cost across all workflows and repos, with p50, p95, p99, queue wait and a week over week trend