Personal Workspaces

Personal Workspaces give every organization member a private, organization-managed place to create individualized skills. LocalSkills provisions the folder and access grant automatically; integrations target the semantic personal destination instead of managing folder paths or per-user onboarding automation.

Enable and provision

An owner or administrator opens Organization > Personal Workspaces, chooses a namespace such as individuals, and enables the feature. Existing members are backfilled. Every later membership automatically creates a durable provisioning request.

Each member’s workspace folder is named after the local part of their email address, lowercased with dots and other separators turned into hyphens: jane.doe@example.com gets a workspace named jane-doe at the path individuals/jane-doe. The folder name and its path segment are always the same. Members whose email yields no usable name fall back to their username, then their display name, and finally to member if neither yields a usable name either. When two members’ emails map to the same path, the second member gets a deterministic suffixed path.

If a folder already exists at the chosen namespace path, enabling adopts it as the managed namespace instead of failing; a folder that is already a managed Personal Workspaces object still conflicts. During the backfill, a folder that already sits at a member’s expected path (for example a hand-built individuals/jane-doe) becomes that member’s workspace, keeping its skills in place, unless it is already another member’s workspace, in which case the member gets a deterministic suffixed path instead. Adopted folders become restricted managed objects.

Each member workspace is a restricted child of the managed namespace with a direct editor grant for that member. Grants never exceed organization-role permissions, so a read-only member remains read-only.

Renaming or moving the namespace onto a path where an unmanaged folder already exists adopts that folder as the new namespace root: the current root’s contents move into it (folder, grant, and skill identifiers preserved), the folder becomes restricted, and the old root is removed. Adoption is refused when the folder is already a managed Personal Workspaces object, or when the current namespace and the folder both contain an entry at the same path; move or rename one of the entries first.

Publish to your workspace

The dashboard exposes My personal workspace. The CLI and MCP use the same semantic destination:

localskills publish ./my-skill --personal

create_skill({
  name: "My Skill",
  content: "...",
  tenantId: "org-id",
  destination: "personal"
})

Personal publications are always private. Responses include the physical folderId, but callers should keep using the personal destination for future creates.

Find personal skills

MCP callers use search_skills with scope: "personal". This keeps discovery in the existing search tool while making the security boundary explicit. The CLI exposes the equivalent filter through localskills list --personal.

Membership and lifecycle behavior

• Joining an enabled organization schedules provisioning atomically.
• Removing a member makes their binding inert; content is retained.
• Rejoining reuses the existing workspace when it remains valid.
• Changing the namespace path preserves child folder and skill IDs.
• Administrators can inspect pending, failed, active, and former-member workspaces.

See Folders & Access Control for the underlying restriction model and MCP Server for complete tool schemas.