> ## 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. # How workspaces work > How personal and shared workspaces scope skills, who can see them, and when to use each. Workspaces organize skills around the people who use and maintain them. Your personal workspace holds your own working set. Shared workspaces give a team one place to discover, review, and improve the skills it relies on. The workspace a skill belongs to determines where it appears, who can see it, and who can update it. ## Why workspaces matter Workspaces keep a team's shared skills from blending into every person's local experiments. They set the visibility and membership boundary around a skill, while the skill record retains its source and version history. Common uses include: * Finding the skills already installed for Claude Code or Codex on your computer. * Giving a team a shared home for skills it maintains. * Separating departments, programs, or teams that need different access. ## Personal and shared workspaces | Workspace | Best for | Access | | - | - | - | | **Personal** | Skills from your computer and private drafts | Only you | | **Shared** | Skills maintained and used by a team | Workspace admins, builders, and viewers | ### Personal workspace Agent Registry creates one personal workspace for you. The desktop app uses it as the home for global skills found on your computer, including: * Claude Code skills in `~/.claude/skills`. * Skills from installed Claude Code plugins under `~/.claude/plugins`. * Codex skills in `~/.codex/skills`. The app imports the complete skill folder, including supported reference files, scripts, and small assets. When identical skill content appears in more than one location, it is imported once. Skills installed from your organization's marketplace are not imported back into the registry. Agent Registry keeps global Claude skills, Claude plugins, and Codex skills in your personal workspace while recording the source of each skill. A personal workspace has no member list. Other people cannot join it, and you cannot leave or delete it. Publish or import a skill into a shared workspace when teammates need to discover or maintain it. ### Shared workspaces A shared workspace gives a team a stable home in the registry. Its members can discover the same skills, while roles control who can view, contribute, or manage them. Shared workspaces can be nested. A parent can represent a department or program, with child workspaces for teams that need their own context. For example, an Engineering workspace can contain separate Platform and Developer Experience workspaces. Creating workspaces, changing their hierarchy, and managing members are administrative actions. See [Manage workspaces](/administer/workspaces) for the exact steps and required roles. ## Choose where skills belong Keep a skill in your personal workspace while you are testing it or while it only supports your own work. Use a shared workspace once a team depends on it, reviews it, or needs a stable owner beyond one person. Importing a skill into a shared workspace does not remove the local copy from your computer. The workspace controls the registry copy and its access; the source information still records where the skill came from. Use this rule of thumb: * **Personal:** you are still trying the skill or it only supports your work. * **Shared:** the same people need to find, use, and maintain the skill. * **Child workspace:** a team needs its own owner, membership, or access boundary. A shared workspace groups skills by who maintains them, not by where they came from. For example, a Platform workspace might contain a deployment skill synced from GitHub and an incident-review skill published from the CLI. Each skill keeps its own source. ## Start small Ask an administrator to create a shared workspace when the work has a durable owner, a recurring group of collaborators, or a distinct access boundary. Keep using an existing workspace when the same people own and use the skills. Start with a few broad workspaces. Add a child workspace when it makes the right home for an artifact easier to identify. ## Learn more Find a workspace's skills, members, activity, and usage. Pick personal or shared scope, publish, and confirm the right people can find the skill. Fix skills that do not appear and workspaces you cannot join or add to. Create shared workspaces and manage their details, hierarchy, and members. ## Access and visibility Agent Registry checks your signed-in identity and workspace permissions before showing or changing context. Selecting a workspace identifier does not grant access to that workspace. ## API boundary The public API reference does not expose workspace administration endpoints. Use [Administration → Workspaces](/administer/workspaces) to manage workspace details, members, and roles. Compare workspace roles and membership actions. Learn how identity and workspace permissions apply to API requests. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.