Review GitHub Actions changes with an agent skill

Review GitHub Actions changes with an agent skill, preserve required checks, and separate local syntax evidence from measured CI improvements.

A workflow can become cheaper by running fewer jobs and less useful by skipping the very checks your project needs. Start with the decision each job supports. Then use a skill to propose a small change, document its assumptions and collect evidence before calling it an improvement.

Start with the repository's obligations

The GitHub Actions Efficiency Review skill is a community contribution from GitHub Awesome Copilot. Its instruction file and four reference files cover audit order, YAML patterns, reporting and review. BB Skills preserves those files and the MIT notice from a fixed source revision; independent packaging is not a GitHub certification.

Before giving an agent a task, gather the current workflow files and the project's CI policy. List release checks, migration tests, shared-library validation and promised runtime or platform support. For each job, write the decision it protects and the owner who can approve removing it. An undocumented matrix leg needs investigation, not automatic deletion. A workflow-file change can alter the whole pipeline even when application source has not changed.

Read the package file viewer and checksum before installing. The ZIP supplies instructions, not a GitHub CLI executable, authenticated account or permission to push. Your agent client and any model access are separate prerequisites. Begin with local read-only review if live account access is unnecessary.

Measure runner time and feedback time separately

Choose a comparable baseline sample before changing the configuration. Keep event type, runner class, matrix dimensions and input scope visible in your notes. Include failed or cancelled runs when they matter to the question. Compare another sample after the change, allowing caches to warm; a single unusually small pull request is weak evidence.

Total runner time and the time a developer waits for feedback answer different questions. In a synthetic example, two independent jobs lasting three and five minutes use eight runner-minutes. Parallel execution can finish in roughly five minutes if queueing and setup are ignored. Serial execution uses the same runner time while taking roughly eight minutes. These numbers illustrate the distinction; they are not measurements of this Skill or your repository.

If there is no run history, label the report static-only analysis. Describe the proposed mechanism and the missing measurement. Do not invent a percentage reduction, a bill estimate or a successful cache hit from YAML alone.

Use local linting as one layer of evidence

actionlint is an open-source static checker for workflow files. Our linked scenario uses its pinned 1.7.12 release with synthetic YAML in a container that has no network access, GitHub login or repository credentials. No GitHub workflow or AI client runs in that check.

The fixtures cover a cache key, concurrency expression and path filter; opt-in maintenance; and a compatibility matrix with job dependencies. Negative fixtures deliberately include an unknown context property, undefined matrix dimension, missing dependency, dependency cycle, invalid permission value, conflicting path filters and malformed YAML. The public scenario records the exact outcomes and artifact hashes.

A valid file is not proof that a cache restores, a runner has the expected toolchain, a stale run cancels safely or a required check remains available. Our fixture disables integrations with external shell and Python linters; it is not a complete script or security audit. Inspect commands and third-party actions separately, then decide which runtime observations you still need.

Keep required checks when narrowing triggers

A path filter should follow the dependency surface, including workflow definitions, lockfiles, build configuration and shared code where relevant. Review representative changes outside the main source directory before assuming a job is unnecessary.

GitHub's workflow syntax reference explains that skipping an entire workflow with filters can leave its required check pending and block a pull request. Check branch-protection expectations alongside the proposed YAML. Do not treat a successful local lint as evidence that merging will still work.

For a live test, use a repository and branch the owner has authorized. If the zero-cost constraint rules out runner usage, retain the static-only result and the pending validation list. This guide and our published fixture do not dispatch cloud jobs.

Scope concurrency and dependencies deliberately

For ordinary CI, a concurrency key should identify the workflow and the relevant branch or pull-request context. Reusing a group across unrelated workflows can cancel work outside the intended scope. GitHub documents the group behavior in its concurrency guide.

Cancellation needs extra thought for releases, migrations and deployments with side effects. Explain whether interruption can leave partial work and who can authorize the change. Prefer a narrowly scoped proposal over copying a cancellation pattern into every workflow.

Keep a full commit pin and a source review for actions you depend on; a readable version tag in an upstream teaching example is not an immutable production reference. GitHub's secure-use guidance describes that distinction. The directory retains the original example so its provenance stays inspectable.

Review one small patch and its evidence

Ask your agent to return the candidate change, required checks preserved, assumptions, local observations and remaining live checks. Review the diff with the Git commit skill and the local commit review guide. Repository hooks and project rules still apply.

Keep a short record with the input revision, proposed YAML, linter version, exact fixture or command, output, approval boundary and rollback step. After real authorized runs become available, add their identifiers and comparable durations. Preserve the earlier static result instead of rewriting it as a measurement that never occurred.

How this guide was prepared

BB Skills prepared this original English guide with AI assistance, source review and independently constructed workflow fixtures. The resource link provides the preserved upstream files, license, checksum and scoped evidence. The guide explains how to evaluate a proposal; it does not guarantee CI savings, certify security or validate an agent's decisions in your environment.