github-actions-efficiency

What it does

One of 441 skills in GitHub’s awesome-copilot collection (40,312 stars, MIT, checked Oct 2026), added in a single commit on 2026-05-25 and untouched since. The package is five Markdown files: a 79-line SKILL.md entrypoint and four references that load on demand — an audit guide, a patterns file, a reporting guide, and a review rubric. No scripts anywhere.

The core is a four-step audit: measure (an rg sweep of your workflow files plus gh run list), check every candidate fix against five guardrails, keep a ranked top 3 from six named fixes, then verify with a live test push — or say, in writing, that live verification was not possible. The guardrails are the strongest writing in the package. A fix that hides required validation is dropped, not debated. A parallelism cut needs the new critical path within 1.25x of the original. Write-back jobs get flagged and moved to opt-in triggers rather than quietly kept.

The reporting reference deserves its own mention: it forbids claiming exact minutes saved without before/after run data and ships the sentence to use instead. Skills that ship their own honesty constraints are rare.

How the live test went

Greenfield work is the skill’s side door: SKILL.md says to load references/actions.md and define a baseline when no workflows exist, so we did exactly that for our standard brief (Node 20 project; install with caching, lint, test, build; pushes and PRs to main; Node 22 as a second test leg). The with-skill workflow assembled the patterns file’s fragments as written — the manual actions/cache@v4 step over ~/.npm keyed on hashFiles('**/package-lock.json'), and the concurrency block.

We verified both outputs programmatically rather than by eye. Both parse, both carry the same three jobs, the same commands, the same triggers, and the same [20, 22] test matrix: 8 of 8 brief requirements on each side. The single structural difference is concurrency with cancel-in-progress — present with the skill, absent without it. On a branch receiving rapid pushes, that one block is the difference between paying for every superseded run and paying for the last one.

Two findings cut the other way. On caching, the baseline used setup-node’s built-in cache: npm; the skill’s prescribed pattern is the older manual cache step — correct, with a restore-keys fallback the built-in lacks, but a step behind the current idiom. And neither workflow has a permissions: block or a single SHA-pinned action (0 of 9 refs with the skill, 0 of 6 without). That is not this skill’s failure so much as its scope: it never claims security. The sibling skill in the same folder, github-actions-hardening, exists precisely for that half.

Where it falls short

Start with the trigger score, 9 of 15 — the lowest dimension. The description reads “Audit GitHub Actions workflow efficiency and recommend fixes”, full stop. The creation mode our test used is claimed only in a body section titled “Use This Skill When”, which description-based matching never sees. A user asking an agent to “set up CI from scratch” may never load the one skill in the repo that covers it.

Second: there is no complete workflow anywhere in the package. patterns.md gives three fragments — cache, concurrency, trigger scoping — and our with-skill run had to assemble a 69-line workflow from them plus its own knowledge. For a skill whose entrypoint promises a baseline workflow, shipping one finished example would close most of that gap.

Third, smaller: the five-item waste list is printed twice, near-verbatim, in SKILL.md and references/actions.md — the one padding slip in an otherwise tight 270-line package. And if your problem is CI security rather than CI cost, this is simply the wrong folder: permissions, pinning and injection review are next door in github-actions-hardening, and nothing in this skill points you there.