> ## Documentation Index
> Fetch the complete documentation index at: https://platform.atlan.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> To act on Atlan objects, use the Atlan MCP server at https://api.atlan.com/mcp or the atlanai CLI; `atlanai --map json` prints its command map. Run a read-only identity check before any write.
> The docs MCP server at /mcp searches these docs only. It cannot read or change Atlan objects.
> SDK packages: Python `atlanai` (PyPI) and TypeScript `@atlanai/sdk` (npm). Show Python first, then TypeScript.

# Publish skills

> Choose the right publishing method, then verify the skill and its version in Atlan.

Choose a publishing method based on where the skills live and how often they
change. Each method writes a skill in one workspace. None installs that skill
into Claude Code or Codex automatically.

| When you need to | Use | Why |
| - | - | - |
| Move many local skill folders into one workspace | [Atlan Desktop bulk upload](/registry/skills/how-tos/upload-in-desktop) | Review folders before the app uploads them in batches. |
| Publish one local skill or a repository package yourself | [CLI publishing](/registry/skills/how-tos/publish-with-cli) | Validate first and keep the command in your development workflow. |
| Review skill changes in pull requests and publish them after merge | [GitHub SkillSync](/registry/skills/how-tos/sync-from-github) | Keep destinations and publishing rules beside the source, with separate preflight and publish workflows. |
| Ask an agent to inspect a reviewed batch from the current repository | [Claude Code MCP](/registry/skills/how-tos/publish-with-claude-code) or [Codex MCP](/registry/skills/how-tos/publish-with-codex) | Use MCP for inspection, then publish through the Atlan CLI. |

## Prepare every package

1. Put `SKILL.md` at the package root with only the references, templates,
   examples, scripts, and small assets the skill needs.
2. Remove secrets, customer data, and private source material.
3. Decide whether the skill belongs in your personal workspace or a shared
   workspace. Choose shared scope only when the team needs to discover or
   maintain the same registry record.

## Verify the published skill

1. Open the resulting skill profile and inspect **Source**.
2. Confirm the live version, the expected file list, and the source details.
3. Retrieve the selected version when a consuming environment requires a local
   copy, then compare its manifest with the source package.
4. Review any available relationship and usage evidence before treating the
   version as the team's maintained copy.

Do not claim publication succeeded until the version is discoverable in the
intended scope and the expected package files are visible.

## Correct a release

Publish a corrected package when source content changes. If you need to return
to an earlier package, use **Source** to select that version and choose
**Restore**. Restore publishes a new version and keeps history intact.