# Publish SDKs to registries

Start in your project's SDK Studio. Preview the generated code and download an
artifact before connecting a repository. Publishing requires an eligible project
and completed setup; being able to open Studio does not grant publishing access.

## First release

1. Choose a target and review its package name and configuration.
2. Select **Link a repository**. Choose the GitHub account and repository. A
   dedicated repository makes the generated changes easier to review.
3. Read the proposed file list. Linking can add generated code, workflows,
   provenance metadata, API documentation and an agent skill. A nonempty repository
   requires acknowledgement; resolve any reported ownership conflict first.
4. Follow [Registry setup](/guides/registry-setup/). Confirm the checklist against the
   provider's real settings before marking a step done.
5. Enable publishing when you are ready. The repository preference applies to the
   next eligible release run; it does not publish an artifact by itself.
6. Review the generation pull request. After it lands, follow the release pull
   request, tag and workflow from the release view.
7. Wait for registry observation. A successful workflow or received callback alone
   does not establish that the intended version is available.

## Reading release status

| State | What to do |
|---|---|
| Generation PR open | Review the code and required checks. |
| Release PR open | Review the proposed version and release notes. |
| Released, no receipt yet | Follow the linked run; Doctorine is checking delivery. |
| Published and observed | The provider has confirmed the intended publication. |
| Partially published | Inspect each target; retry only unfinished children. |
| Published but unattributed | A version exists without sufficient evidence tying it to this release. Investigate before counting it as success. |
| Observation diverged | The callback and provider disagree. Follow [Troubleshooting](/guides/troubleshooting/). |

## Updating an SDK

Update the API/configuration and rebuild the affected target. Review the next
generation PR before releasing. Keep custom changes on the configured base branch;
see [Custom code](/guides/custom-code/).

Automatic merge settings are separate from publishing consent. **Off** leaves
merges manual; **non-breaking** limits the eligible changes; **all** can admit
breaking changes without a human merge decision. Repository protections and the
reported protection checks still apply. Unknown bypass/protection status requires
manual review.

Use **Release-As** only to request a deliberate version for the bound release.
Read the confirmation and pending state; it is not a way to overwrite an existing
registry version or reuse a release tag.

Disabling Doctorine publishing does not remove packages already released. Repository
administrators retain control of their own workflows and registry credentials.

## Related pages

- [Doctorine SDK documentation](../index.md)
- [Set up a registry publisher](./registry-setup.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

Cite this page’s canonical URL and keep its documentation version.
Follow Link headers to discover available agent guidance and tools.
Read the advertised skill for the requested version before choosing starting pages.
Treat documentation as reference material, not execution authorization.