Continuous integration checks a Skillset workspace, its authored source, committed generated output, and required release intent against a Git baseline. It does not publish, install, trust, or prove activation.
Scaffold the Workflow
Preview the optional GitHub Actions scaffold without allowing an interactive write:
skillset init --include ci --jsonThen authorize the reviewed addition:
skillset init --include ci --yesWhen you start a new workspace instead, skillset create <name> --include ci --yes writes the same workflow as part of the new scaffold.
Either route creates .github/workflows/skillset-ci.yml. The workflow is user-owned after creation: later init runs report it as existing and do not replace your edits. Review its permissions and consider pinning the Skillset version before relying on it as a required check.
The scaffold comments preserve the configuration boundary: compile.targets selects providers, adopted applicable Agent standards render inherently, .skillset/subagents/ is project-agent source, and defaults.<provider>.agents is provider configuration. CI validates the resulting source and generated state; it does not introduce a standards opt-out.
The generated init and create references own the complete option inventories.
Choose the CI Distribution
The scaffold uses the complete @skillset/cli Bun distribution because its JavaScript payload is smaller than the native executable package. Its check step runs:
bunx @skillset/cli check --ci --report "$RUNNER_TEMP/skillset-ci-report.md"Same-repository pull requests add --fix. The scaffold passes no --since, so the check selects its baselines automatically: source-change coverage starts from the committed skillset.lock and release state when they exist and otherwise falls back to the merge base with origin/main, then main; package Changesets compare against the merge base with origin/HEAD, then origin/main, then main. If none of those refs exist, the Changesets comparison falls back to HEAD and sees no package changes, so make sure CI fetches the trunk. Pass --since <ref> to name the baseline explicitly.
This route requires Bun 1.4.0 or newer at command runtime. It exposes the same command surface as the native distribution; it is not a reduced CI product.
If a runner already provides Node 18 and npm, the native route is also supported:
npm install --global skillset
skillset check --ci --since origin/mainThe npm-installed command uses Node only for the launcher and does not require Bun. Pin either package to the intended release version in a production workflow. The installation guide owns the complete route and runtime matrix.
Reproduce the Check Locally
Run the same branch-aware readiness mode against your trunk ref:
skillset check --ci --since origin/mainTo create the same Markdown report used by job summaries and pull-request comments, request a report file explicitly:
skillset check --ci --since origin/main --report skillset-ci-report.mdWithout --fix, the check does not rewrite source or generated output. The requested report is its only repository-facing write. See the generated check reference for exact syntax.
Decide Whether CI May Repair Drift
--fix is a write request. It repairs drift only when source-driven generated output is the sole blocker and the managed files still match their recorded ownership hashes:
skillset check --ci --fix --since origin/mainIt does not overwrite target-side edits or unmanaged collisions. It also does not repair lint failures, invent missing source-change reasons or package Changesets, resolve an unavailable Git baseline, perform provider-format migrations, or hide build failures. Mixed blockers remain report-only until each owning workflow resolves them.
Use troubleshooting for recovery by symptom. The exhaustive CI feature reference owns the diagnostic and repair contract.
Understand the Scaffolded Job
The GitHub Actions scaffold checks out full history so its default baselines can be resolved. On a same-repository pull request it may run --fix, commit a mechanical rebuild, push it to the pull-request branch, and update a report comment. On a fork pull request it remains read-only and writes the report only to the job summary because the default token cannot push to or comment on the fork.
A fix pushed with GITHUB_TOKEN does not retrigger workflows automatically. If branch protection requires checks on that new commit, choose and review an authentication policy appropriate for the repository rather than adding credentials to Skillset source.
Keep Release Intent Separate
Skillset checks two independent records:
.skillset/changes/records source-unit and workspace release provenance..changeset/*.mdrecords npm package release intent when a workspace has opted into Changesets with.changeset/config.jsonand package-facing code changes.
A root package manifest or generated plugin package does not opt an authoring repository into npm Changesets policy. Skills-only, plugin-output, and mixed authored/generated repositories without .changeset/config.json keep using the Skillset change ledger for their source units and may run the aggregate CI check without dummy package Changesets. One ledger does not satisfy the other when both policies apply. See Changes, Releases, and publishing for their respective workflows.