Skip to main content
Teams that keep skills in a git repo can publish them from the pipeline on merge, so the registry always mirrors the reviewed state of the repo.
In CI, your merge review is the approval step — --yes exists exactly for this. Agents must never use it; the interactive approval rules in Trust & approvals apply to humans and agents, not to pipelines you control.

​
1. Get a token

Device tokens are created through the browser login flow and stored in ~/.masterskills/config.json. For CI:
  1. Run masterskills login once on a workstation (consider a dedicated service account so revocation doesn’t take a person’s machine offline).
  2. Copy the token value from ~/.masterskills/config.json.
  3. Store it as a CI secret, e.g. MASTERSKILLS_TOKEN.
The MASTERSKILLS_TOKEN environment variable takes precedence over any stored config, so the CI job needs no config file. The device shows up in the panel like any other and can be revoked there at any time.

​
2. Publish non-interactively

Publishing unchanged content is effectively a no-op — versions are content-hash based, so re-running the job doesn’t create noise. The server-side secret scan still runs on every publish and rejects findings with a non-zero exit, failing the job loudly rather than shipping a secret.

​
Environment variables