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

# Skills

> Find, assess, use, and improve reusable skills.

A skill is a reusable package of instructions and supporting files for a
specific job. It gives a team one record for the instructions it relies on,
the version an agent received, and the evidence available after use.

Use a skill profile to answer four practical questions before you adopt or
change it:

1. **Does it fit this job?** Read the summary, prerequisites, and trigger
   guidance.
2. **Can I trust this version?** Review its source, owner, and version history.
3. **What else does it affect?** Check dependencies and relationship signals.
4. **Is it helping?** Review the available usage evidence and linked runs.

<Note>
  Skill names are unique within a workspace. Use a name that describes the job,
  such as `meeting-notes-to-actions`, rather than the team or person who created
  it. The same name can be used in another workspace.
</Note>

## Read every skill surface

| Surface | Use it to | Availability |
| - | - | - |
| **Overview** | Check what the skill does, when it applies, prerequisites, source-file count, and the activity summary. | Available for every skill you can open. Run metrics populate after recorded use. |
| **Source** | Read the package files, provenance, and version history. | Available when the package is visible to you. |
| **Relationships** | Review declared dependencies and dependents, then assess duplicate or conflict candidates. | Available when relationship data exists. |
| **Usage** | Review trace-backed runs, models, tools, people, versions, and linked traces. | Available only when attributable execution data exists. |
| **Security** | See the planned scan, findings, trend, and release-gate experience. | **Coming soon.** It is not a scan result. |

Select **Overview** first, then move to the surface that answers the question
you have. Do not treat an empty activity panel as a quality result or a missing
Security result as a passed review.

## Follow a skill from discovery to improvement

Start in the workspace where the skill should be visible. Browse or search for
the skill, open its profile, then choose the next action that matches your job.

<CardGroup cols={2}>
  <Card title="Discover and use a skill" icon="magnifying-glass" href="/registry/skills/how-tos/discover-and-use">
    Find the right skill, assess its current version, and open it in a supported environment.
  </Card>

  <Card title="Publish and version a skill" icon="upload" href="/registry/skills/how-tos/publish-and-version">
    Prepare a package, publish it into the right workspace, and verify the new version.
  </Card>

  <Card title="Sync skills from GitHub" icon="code-branch" href="/registry/skills/how-tos/sync-from-github">
    Review repository changes in a pull request and publish approved versions from a protected branch.
  </Card>
</CardGroup>

## Keep Git-backed skills current

SkillSync connects a repository path to the corresponding skill record. A pull
request report classifies changed direct-child `SKILL.md` definitions as added,
updated, or removed, and maps supporting-file changes to the owning skill. After
the change reaches the protected publish branch, the publish workflow creates
the new skill or appends a version and waits up to 60 seconds for its Registry
security scan.

GitHub remains the source of truth. Use the skill's **Source** view to verify the
repository, commit, path, files, and contributor provenance attached to the
published version.

## Inspect the record

<CardGroup cols={2}>
  <Card title="Source and versions" icon="files" href="/registry/skills/concepts/source">
    Inspect the package, compare an earlier version with live, or restore one safely.
  </Card>

  <Card title="Security" icon="shield-check" href="/registry/skills/concepts/security">
    See what the planned security review will cover. It is not a scan result yet.
  </Card>

  <Card title="Relationships" icon="diagram-project" href="/registry/skills/concepts/relationships">
    Check dependencies and review possible duplication or conflicting guidance.
  </Card>

  <Card title="Usage" icon="chart-line" href="/registry/skills/concepts/usage">
    Interpret the trace-backed activity that Atlan can attribute to the skill.
  </Card>
</CardGroup>

## Choose the right workspace

Keep an early or personal skill in your personal workspace. Move to a shared
workspace when a team needs the same record, a clear owner, or its own access
boundary. The source stays attached to the skill record; publishing it into a
shared workspace does not remove its local source.

<Card title="Choose a workspace for a skill" icon="folder-tree" href="/registry/workspaces/how-tos/organize-artifacts">
  Compare personal and shared scope before publishing or sharing a skill.
</Card>