Workspaces

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

​

Personal workspace

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

Atlan imports the complete skill folder, including supported reference files, scripts, and small assets. When identical skill content appears in more than one location, Atlan imports it once. Skills installed from your organization’s Atlan marketplace are not imported back into the registry. Atlan 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 for the exact steps and required roles.

​

Choose where a skill belongs

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.

​

Start with a small structure

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

​

Access and visibility

Atlan 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 to manage workspace details, members, and roles.