Pin actions

My personal config files for AI Agents

Install

npx -y skills add rmuraix/agent --skill pin-actions

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Ensure GitHub Actions workflows use up-to-date and securely pinned action versions. Use this skill whenever the user asks to write, create, edit, review, or update a GitHub Actions workflow file (.github/workflows/*.yml or *.yaml), add a new action step, or audit existing workflows for outdated or unpinned versions. Also trigger when the user mentions actions like "actions/checkout", "uses:", or any GitHub Actions step configuration.

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

3.3 KB, as published. Nobody here has run it

pin-actions: GitHub Actions Version Pinning

Whenever you write or edit a GitHub Actions workflow, follow these rules to ensure every uses: step references the correct, up-to-date version.

Pinning strategy

There are two categories of actions:

Official GitHub actions — owner is actions or github (e.g., actions/checkout, actions/setup-node, github/codeql-action):

A floating major-version tag like @v4 is acceptable.
Still check that the major version is current — using @v3 when @v4 exists is a problem.

Third-party actions — every other owner (e.g., docker/setup-buildx-action, aws-actions/configure-aws-credentials, google-github-actions/auth):

Pin to the full commit SHA.
Add an inline comment with the corresponding tag. This is the format Renovate and Dependabot generate and expect when managing SHA-pinned actions — without the comment these tools cannot determine the current version and will skip the dependency.

Example of correct third-party pinning:

- uses: docker/setup-buildx-action@f95db851eec2b9a1e0f0b694cf0cd01abb40e84a  # v3.0.0

How to look up the latest version and SHA

Use the gh CLI. For any action owner/repo:

repo=owner/repo
tag=$(gh release view -R "$repo" --json tagName --jq .tagName)
sha=$(gh api "repos/$repo/commits/$tag" --jq .sha)
echo "tag=$tag  sha=$sha"

Run this for every action in the workflow before writing or modifying it.

If gh release view fails (no releases, only tags), fall back to:

tag=$(gh api "repos/$repo/tags" --jq '.[].name' | sort -V | tail -n 1)
sha=$(gh api "repos/$repo/commits/$tag" --jq .sha)

Step-by-step workflow

Collect all actions — scan every uses: line in the workflow.
For each action, extract owner/repo and the currently referenced version.
Look up latest — run the commands above to get $tag and $sha.
Decide the correct reference:
- Official (actions/* or github/*): use @<major-tag> (e.g., @v4). If the major version is behind, update it.
- Third-party: use @<full-sha> # <tag>.
Apply the correct reference in the workflow file.
Report what was changed and why, so the user can verify.

When the right choice is unclear

Some organizations occupy a grey zone (e.g., hashicorp/setup-terraform, slsa-framework/slsa-github-generator). When you are not sure whether an owner qualifies as "official enough" for loose tag pinning, ask the user before writing the workflow:

hashicorp/setup-terraform is a third-party action. Should I pin it to a SHA, or is the major-version tag acceptable for your use case?

Example output

Before:

- uses: actions/checkout@v2
- uses: docker/setup-buildx-action@v2

After running this skill:

- uses: actions/checkout@v4
- uses: docker/setup-buildx-action@f95db851eec2b9a1e0f0b694cf0cd01abb40e84a  # v3.0.0