# 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.

| Target | Publishing destination | Setup supported by Doctorine |
|---|---|---|
| TypeScript, MCP, CLI | npm | First-package bootstrap, then trusted publishing |
| Python | PyPI | Pending or existing trusted publisher |
| Go | GitHub tag | Module path and version tag; no registry token |

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

## Shared GitHub setup

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.

## npm

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](https://docs.npmjs.com/trusted-publishers/).

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.

## PyPI

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](https://docs.pypi.org/trusted-publishers/creating-a-project-through-oidc/).

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.

## Go

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](https://go.dev/doc/modules/publishing).

## Rename or transfer

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.

## Related pages

- [Doctorine SDK documentation](../index.md)
- [Publish SDKs to registries](./publish-sdks.md)
- [Doctorine App permissions](./app-permissions.md)
- [Keep custom code during regeneration](./custom-code.md)
- [Plans, disable and offboarding](./plans-and-offboarding.md)
- [Troubleshoot an SDK release](./troubleshooting.md)

# Agent Instructions

This portal answers questions programmatically. To receive a synthesized,
source-cited answer instead of crawling page by page, append the `?ask=`
query parameter to any page URL on this site:

    /guides/quickstart?ask=how+do+I+authenticate

Optional parameters:

- `&goal=<what-you-are-trying-to-do>` steers the answer toward your
  objective (e.g. `&goal=write+a+python+client`).
- `&version=<label>` scopes the answer to a mounted version when the
  portal publishes more than one.

The response is `text/markdown`: the answer followed by a `# Sources` list
of the portal pages it was grounded in. Status codes are the contract:

- `200` — the answer; `402` — the portal owner’s plan or answer credits are
  exhausted (surface this to your operator; do NOT retry); `429` — you are
  rate-limited; back off for the `Retry-After` seconds; `503` — the answer
  lane is temporarily unavailable; fall back to crawling the `.md` pages.

For the full corpus map read `llms.txt` at the site root; for the tool
surface (search + page fetch as MCP tools) see `/mcp`.
