GitHub Actions

Browse the public template catalog and skill-checks.yml source. Source templates contain placeholders. Use the release-generated file when onboarding; do not substitute main or latest for its immutable versions.

Start with the filled-in publisher template and follow the publisher setup guide. The main steps are:

1. Enable Settings → Pages → Source: GitHub Actions and initialize the gh-pages report-history branch. For private reports, an administrator must also select Private site visibility in GitHub’s settings; see the private-hosting requirements below. Preserve any existing site or history.
2. Add publish-skill-reports.yml with your Pages URL. Keep the evaluator and publisher versions supplied by the release.
3. Grant the scan workflow id-token: write, then approve its exact contents in the publisher’s trusted-caller-blobs input. Compute the value with git hash-object .github/workflows/skill-checks.yml; refresh it whenever that scan file changes.
4. Merge both workflow files into the default branch. Open a new skill PR to test checks, hosting and feedback together.

Keep the Skill checks workflow name, scan filename and default artifact name. The publisher uses GitHub’s automatic token; organization policies must allow its permissions and referenced actions. Copying a second file alone does not finish setup.

Comments are posted on open, current-head PRs from branches in the same repository. Fork-origin PRs keep their available reports in Actions. Pages is public unless explicitly configured as private; repository privacy alone does not make its Pages site private. Reports may contain source excerpts and unmerged findings. Use downloadable artifacts when public hosting is unsuitable.

Access-controlled Pages requires a private or internal project repository owned by a GitHub Enterprise Cloud organization. An administrator first selects GitHub Actions and Private in Settings → Pages. The REST API cannot set Pages visibility. Personal repositories cannot host private Pages.

The CLI verifies the existing private site and uses its assigned *.pages.github.io URL. It accepts an existing SkillEvaluator report site or a newly configured empty private site, and preserves unrelated websites. If private hosting is unavailable, choose checks only. See private report hosting for the guided path and GitHub’s access-control requirements.

This workflow runs independently. Existing workflows remain separate; it does not automatically wait for them to finish. Configure explicit workflow dependencies if your pipeline needs that ordering.

auto selects affected skills on pull requests. Pushes to the default branch and manual runs scan the configured collection. all scans that collection each time. No changed skills is a successful Skipped result, not a scanner pass. Changes to shared files outside the skill roots are not inferred dependencies; use all when they should trigger a full scan. Selection is capped at 100 skills. Timeouts retain completed results and mark unfinished work incomplete. The workflow scans up to four skills at once; scan-workers accepts 1–16.

After the first run, select its scan check in GitHub branch rules. The current template emits skills / Tier 1 scan; use the actual check name shown in your repository. min-score sets the quality threshold; required security, schema and other checks remain independent. This integration runs Tier 1 only.

Confirm setup is on the default branch and the PR is eligible for comments. Open Publish skill reports to see whether deployment completed. If hosting was skipped, check the scan’s id-token: write permission and trusted-caller-blobs value. A new scan must use the updated workflow; rerunning an old job keeps its original workflow. The scan’s downloadable report remains a separate way to inspect available findings.

Keep the component reference in your existing caller, for example your-org/ci/.github/workflows/skill-checks.yml@v3, then run skillevaluator ci init in each consumer repository. The CLI recognizes .github/workflows/skill-checks.yml with the name Skill checks and one reusable scan job. It preserves inputs, triggers and the version tag while adding the publisher and any needed scan-job id-token: write permission.

The component maintainer must first grant id-token: write in the job calling the evaluator. The CLI checks that prerequisite before applying reporting setup; a consumer permission alone cannot grant it downstream.

With delegation, the publisher approves the exact component path and tag in trusted-wrapper-workflows and delegated-evaluator-wrapper. Updating v3 then updates future scans centrally, with no consumer workflow edit. Published execution receipts record the resolved component and evaluator commit SHAs for each run. The component still pins its evaluator and image immutably. Use a full component SHA when you want to hold that version fixed.

Use SkillEvaluator 0.7.2 or later and its reviewed publisher for these delegation inputs; the archived 0.7.1 publisher does not. Direct callers keep an immutable evaluator approval. For manual configuration, follow the shared-workflow setup guide. PR comments follow successful report deployment; private reports require the private Pages setup described above.

Default Tier 1 checks use no model key. Dependency audits can contact vulnerability services and submit package metadata; packages are not installed and build scripts are not run. Optional LLM checks use a separate manual workflow, your provider key and provider charges. They send selected content to that provider and are outside the default publisher allowlist.