github-actions-optimizerlisted

A workflow that takes 22 minutes and costs you a fortune in minutes is rarely slow for one reason — it's usually re-downloading dependencies every run, running serially what could run in parallel, and building branches no one is waiting on. And the same file is often a supply-chain liability: a third-party action pinned to `@v3` can be repointed under you, and a `write-all` token plus `pull_request_target` is one malicious fork PR away from leaking secrets. This skill measures before it touches anything, then ships fixes ordered by payoff — biggest time or security win first — as concrete YAML diffs. ## When to use this skill - CI wall-clock is the bottleneck on every PR, runs queue behind each other, or the monthly Actions bill is climbing. - A job re-installs the whole dependency tree or rebuilds from scratch on every run, with no cache or a cache that never hits. - The workflow runs on `pull_request` / `pull_request_target` from forks and you haven't audited what secrets and permissions are exposed. - You inherited a workflow that pins actions to floating tags (`@v4`, `@main`) and grants the default broad `GITHUB_TOKEN`. ## When NOT to use this skill - The slowness is in your test suite itself (flaky retries, an N+1 in integration tests) rather than the CI plumbing — fix the tests; faster runners won't save a 9-minute test that should take 90 seconds. - You need a workflow authored from scratch for a new stack — that's scaffolding work; this skill optimizes and hardens