Reviews ONE GitHub Actions workflow file (YAML) for the five mistakes that let an outsider run code or read secrets in your pipeline, and lists only those, one line each with a fixed code, the place, why it is dangerous and the fix - or exactly No findings. It catches text from an issue, pull request, comment or branch name pasted straight into a shell step, a pull_request_target or workflow_run job that checks out and runs the code of the pull request, a third-party action pinned to a tag or branch instead of a full commit hash, a missing or too wide permissions block, and a secret that is printed or handed to code you do not control. It leaves out the safe look-alikes, such as untrusted text passed through an env variable and quoted, or first-party actions pinned to a version tag. Use to review a workflow before merging it, to audit the pipelines of a repository, or to gate a pull request that edits a workflow file.
GitHub Actions Security Review is a tested SKILL.md that reviews ONE GitHub Actions workflow file (YAML) for the five mistakes that let an outsider run code or read secrets in your pipeline, and lists only those, one line each with a fixed code, the place, why it is dangerous and the fix - or exactly No findings; an agent buys it once for $0.01 over x402.
Not for
Reviewing the code a workflow builds, repository or organization settings, scripts that a workflow calls but does not paste, and self-hosted runner hardening. It reads one pasted workflow file and judges only what is written in it.
Tested, honestly
Tested 2026-10-19 with a strong and a weak model.
- SonnetStrong model, claude-sonnet-5-5
- Right on all 3 cases, read by hand. On an issue-triage workflow it named the issue title pasted into a shell step as one line and left out the issue body passed through an env variable and the first-party checkout pinned to a tag. On a pull_request_target workflow it gave exactly two lines, the checkout of the pull request head that is then built and tested, and the community action pinned to a tag, and left out the action pinned to a commit hash. On a clean deploy workflow it answered exactly No findings.
- HaikuWeak model, claude-haiku-5-5
- Right on 2 of 3 cases, read by hand. It found the title injection and kept the safe env-passed body out, and it answered exactly No findings on the clean workflow. On the pull_request_target workflow it gave both expected lines and a third, a secret exposure for the token the checkout step leaves in the git config; the skill defines that code for printed secrets and secrets handed to code you do not control, so the check counts the extra line as a miss. Read by hand it is a defensible remark, but it is outside the definition, and it is recorded as a wrong answer.
Full test summary
Example
Our own test text, before and after the skill ran. Excerpts only.
English · claude-sonnet-5-5
Before
name: PR checks
on:
pull_request_target:
types: [opened, synchronize]
permissions:
contents: read
pull-requests: write
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
ref: ${{ github.event.pull_request.head.sha }}
- uses: actions/setup-node@v4
with:
node-version: 20
- name: Detect changed files…
After
PRT-CHECKOUT — job test, steps "actions/checkout" then `npm ci` and `npm test` — the `pull_request_target` trigger checks out `github.event.pull_request.head.sha` and runs it, so any fork author can run their own code in a job with a write-scoped token — use the `pull_request` trigger for building and testing, or split into an unprivileged test workflow and a separate `workflow_run` job that…
What is in the file
- The answer
- What counts as untrusted
- The codes
- How to read the file
- Rules
- Work in this order
- Short example
Languages
English. Tried in: English.
License
Perpetual, non-exclusive; use and modify for yourself incl. paid work; no resale or republishing. Holder: Georgi Kalchev, aiskills402.com. Full terms.
Versions
Current version 1.0.0, updated 2026-10-19. Whoever bought an earlier version gets new ones free through the same re-download token.
v1.0.0 · 2026-10-19
First release, written in the light-test trial of 19 October 2026 (three cases, price $0.01). The idea is ours; no foreign skill was opened, facts come from public guidance (see notes/ideas.md). Output: one line per finding with a fixed code, or exactly `No findings.`
Test: three cases written by hand (two planted, each with a safe look-alike, one clean control), one run on Claude Sonnet and one on Claude Haiku, no run without the skill, no iteration on the skill text after the runs. `test/control.mjs` shows that the checks pass on the ideal answers and fail on realistic wrong ones. See `test-summary.json` for the verdicts read by hand.
FAQ
Are first-party actions pinned to a version tag reported?
No. The skill states its policy: actions published under the platform's own organizations may be pinned by a version tag, while every other owner needs a full commit hash. A community action on a tag is reported, and a community action on a hash is left alone, even with a version comment beside it.
Is untrusted text passed through an env variable reported?
No. The expression syntax inside a shell step is replaced before the shell runs, so it is reported as script injection. The same text handed over through an env entry and used quoted reaches the shell as a plain variable, which the skill treats as the safe form and leaves out of the list.
How was it tested?
The trial covered an issue workflow with a pasted title, a pull_request_target workflow that checks out and tests the pull request, and a clean deploy workflow, each answered once by Claude Sonnet and once by Claude Haiku. Sonnet matched all three expectations. Haiku matched two and added a secret finding about the checkout token that the skill does not define.
What does a clean workflow return?
Exactly the sentence No findings. and nothing else, so a pipeline can gate a pull request on it. Anything else is one line per problem with a code, the job and step, why it is dangerous and the fix. It never lists the patterns it checked and found safe.