Set up a registry publisher

Use the values shown in your target's checklist. Copy the exact repository owner, repository name, workflow filename and effective environment. Do not substitute the name of another target or an example from this guide.

Agent skills are generation outputs, not registry publication targets. Other registry descriptors do not imply that those destinations are enabled.

Confirm the repository in Studio. Where an environment is required, create the exact environment from the effective configuration; an unset override defaults to publish. Review its protection settings and who can approve a deployment.

The generated release workflow is release-please.yml. Allow the repository's Actions workflows to create release pull requests where GitHub organization policy permits it. Keep token permissions limited to the generated workflow's needs. Complete Studio's publishing-preference step, then enable publishing explicitly.

For a new package, follow Studio's granular-token bootstrap step. Put the short-lived, narrowly scoped credential in the GitHub secret named NPM_TOKEN; never put its value in SDK configuration, a source file, an issue or a screenshot. Check for an existing secret of that name before replacing anything. Complete the common checklist and bootstrap step, then enable the first release. npm requires the package to exist before you can configure its trusted publisher. An existing package can use the trusted-publisher step instead of creating a token.

After the package exists, configure its GitHub trusted publisher using the checklist's exact owner, repository, release-please.yml filename and environment. Permit npm publish. npm currently requires a supported hosted runner, npm 11.5.1 or newer and Node 22.14.0 or newer for trusted publishing. The generated workflow supplies its pinned tools. See npm trusted publishing.

Verify a real trusted-publishing/OIDC release using provider evidence and confirm Studio observes that version. Then remove the repository's NPM_TOKEN secret, revoke the bootstrap credential at npm, and finally mark Delete NPM_TOKEN complete. A published status alone does not prove OIDC was used. The checklist distinguishes npm's trusted-publisher report from ordinary publication; it is not cryptographic attribution to a workflow. Confirm the exact workflow and environment at npm. npm tries OIDC before falling back to NPM_TOKEN, so the presence of that secret does not tell you which authentication method a run used. Keep account recovery material in your password manager. Do not retain a write token as an undocumented fallback.

A new project can use a pending trusted publisher. Enter the intended package name and exact GitHub owner, repository, workflow filename and environment. Registration does not reserve the package name; the first successful publication creates the project. No long-lived PyPI token is required for this path. See PyPI's pending-publisher guide.

For an existing project, add the publisher through its settings and confirm you have permission to manage it. A workflow/environment mismatch must be corrected at the provider; marking the checklist complete does not repair trust.

Confirm that the module path points to the intended repository and that the release version is valid for that module. The workflow publishes the version tag; Go consumers resolve it through the module system. Proxy availability is a separate observation. See Go module publishing.

A repository rename or transfer can invalidate publisher trust. Update the registry's exact repository identity, follow Studio's trust-reconfirmation step, and verify another run before assuming publication has resumed.