I published a GitHub Action for running NVIDIA SkillSpector

I made and published a GitHub Action that runs NVIDIA’s SkillSpector in GitHub Actions.

NPJigaK/skillspector-action

I have been writing more SKILL.md files for AI agents and importing other people’s skills more often, and manually checking “is this dangerous?” during every review was getting pretty tiring. SkillSpector already exists. I wanted something that would run automatically on each PR, so I turned it into a GitHub Action.

Table of Contents

What I built

skillspector-action is a composite action that runs SkillSpector on GitHub Actions and scans repositories that contain SKILL.md files.

The smallest example looks like this.

name: SkillSpector

on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read
  security-events: write

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: NPJigaK/skillspector-action@v1
        with:
          path: .
          changed-only: true
          upload-sarif: true

With upload-sarif: true, the results can also be sent to GitHub Code Scanning. It also outputs normal artifacts and a Markdown summary, so even repositories that do not use Code Scanning can still read the results for now.

Another small but useful part is that it discovers all SKILL.md files under path. If a repository contains multiple skills, you do not have to list each directory by hand.

There is also a status badge you can put in a README.

[![SkillSpector scan](https://github.com/OWNER/REPO/actions/workflows/skillspector.yml/badge.svg?branch=main)](https://github.com/OWNER/REPO/actions/workflows/skillspector.yml?query=branch%3Amain)

Of course, this is not a security certification. Even so, for a public skill repo, being able to show that SkillSpector runs in CI and that the current scan is passing feels pretty meaningful to me. It becomes a small trust signal before someone imports that skill.

What does it check?

SkillSpector is a security scanner for AI agent skills. Its README says it checks patterns such as prompt injection, data exfiltration, privilege escalation, supply chain issues, and tool misuse.

The action I made roughly supports the following.

• Automatically find SKILL.md files under path, including multiple skills in one repo
• On PRs, use changed-only: true to scan only changed skills
• Output JSON / SARIF / Markdown reports
• Upload SARIF to GitHub Code Scanning
• Show the scan status as a README badge
• Fail CI only when fail-on or min-score is set
• Suppress known findings with baseline
• Keep LLM analysis opt-in, with static scan as the default

The part I personally cared about was not failing CI by default. If a workflow immediately fails on high severity findings from day one, it becomes hard to add to existing repos. I think it is easier to start in report-only mode, watch the results, and then tighten it later with something like fail-on: critical.

- uses: NPJigaK/skillspector-action@v1
  with:
    path: .
    changed-only: true
    fail-on: critical
    upload-sarif: true

Things I thought about while building it

Not making LLM analysis the default

SkillSpector can optionally use LLM analysis. But once a GitHub Actions workflow handles an LLM API key, fork PRs and pull_request_target start to feel risky.

So the action defaults to llm: false. Static analysis can run without an API key, and for the first CI integration that feels much easier to place. Repositories that want LLM analysis can opt in with llm: true after understanding how they want to handle secrets.

Only checking changed files in PRs

In a repo that works like a skill registry, scanning everything gets heavier as the number of skills grows. But scanning the whole repo on every PR also feels like too much for a diff review.

So I added changed-only: true. On PRs, it scans only the skill directories touched by the PR. If the diff cannot be obtained, it falls back to full discovery instead of silently checking nothing.

This part is small, but I think it matters quite a bit if the workflow is going to stay in CI.

Adding SARIF output

If the results only appear in logs, they are painful to revisit later. I wanted to track them as security findings on GitHub, so the action can output SARIF and upload it to Code Scanning.

Not every repo uses Code Scanning, though, so it also keeps JSON and Markdown artifacts. I wanted it to be readable first, and still usable properly later.

Trying it in my own repos

I have already added it to a few of my own skill repos.

• jq-cli-skill #7
• unified-adversarial-review-skill #10

It is not a huge action, but at least I now have a setup where SkillSpector runs in CI whenever SKILL.md changes. For this kind of thing, even a rough automatic check on every PR feels a lot stronger than relying on willpower during review.

Closing

AI agent skills are useful, but the mechanism depends a lot on trust. A SKILL.md file looks like plain Markdown, but in practice it can strongly steer what an agent does.

So I think it helps both the person publishing a skill as OSS and the person importing it if there is at least one place to run a mechanical check. I made this action as a small piece for that.

If you maintain a repo with SKILL.md files, I would be happy if you tried it. I will keep using it myself and fix the missing pieces little by little.