Private Registry

A real, hosted registry your whole team shares — versioned and access-controlled. This is where skills your organization owns actually live, not a folder someone forked. Available on the Enterprise tier.

What It Is

The private registry is a shared, org-scoped skill store. Publish a skill once and every teammate can find and install it — no copy-pasting, no "which version is the real one." Every published version is retained; nothing is silently overwritten.

This is different from Private Skills, which is a single-device, Team-tier setting with no sharing at all. If you need your whole org working from the same source of truth, this is that.

Publish & Approval

Publishing isn't instant-live. A version you publish sits as a pending submission until a different team admin reviews it — it's invisible to search, get, and install (even to you, the person who published it) until that happens. Self-approval is blocked at the database level: an admin cannot approve or reject their own submission, no matter how the request is made.

An admin reviewing a submission either approves it (making it immediately visible and installable to the whole team) or rejects it. Both decisions are terminal — once approved or rejected, that exact version can't be re-reviewed. A rejected version can only be superseded by publishing a new version under a new version number.

Publishing requires being signed in personally (skillsmith login) — the team's shared license key alone is no longer enough. This is what makes self-approval blocking and a real submitter identity possible: every submission and every review decision is tied to the actual person who made it, not just "the team."

Access Control

Every team's skills are scoped to that team, enforced differently depending on the operation:

Direct database access (an authenticated dashboard session) is filtered by row-level security — a query literally cannot return another team's rows, and a plain table read never returns a pending or rejected submission to anyone, including the person who submitted it. Seeing your own pending work goes through a separate, dedicated review lookup instead (below), not a plain query.
Listing and metadata lookups (list, get, looking up your namespace) run as your own signed-in account, no admin role required — any team member can do these. Row-level security alone isn't the whole story here: you can belong to more than one team, and row-level security doesn't hide deprecated versions on its own, so team scoping and "approved, non-deprecated only" are also enforced explicitly on every request, on top of row-level security rather than instead of it.
Installing a skill's actual content also runs entirely as your own signed-in account — row-level security applies directly to both the metadata and content reads, and a database-side check confirms the owning team still holds an Enterprise entitlement before any content is returned. This holds whether you install via the CLI (skillsmith registry install) or the MCP tool's own install action; neither path needs anything beyond your own login.
Publishing, reviewing, and admin actions (publish, submissions, approve, reject, deprecate, undeprecate) all run as the signed-in user's own account, so the database's row-level security and admin-membership checks — not application code — decide what's allowed. This is also what makes self-approval blocking real rather than merely convention: the database can name who's asking.

Namespace ownership is enforced at the database layer regardless of which path is used — a database-level check runs on every publish and rejects any skill ID that doesn't match your team's assigned namespace prefix, so a team can't accidentally (or deliberately) publish outside its own namespace.

Tools

Surface	Tool / command	What it does	Tier
MCP	`private_registry_publish`	Publish a new skill version to your team's registry as a pending submission	Enterprise
MCP	`private_registry_manage`	List, get, deprecate, undeprecate, look up your team's namespace, install a skill, view pending/approved/rejected submissions, or approve/reject a submission (the `action` parameter selects which)	Enterprise
CLI	`skillsmith registry install <skillId>`	Install a skill from your team's private registry	Enterprise
Web	Private Registry dashboard (account settings)	Review pending submissions and approve or reject them with a click; also shows every approved skill and its status	Enterprise

Publishing and listing are MCP-only today — there's no CLI command for either yet, only for install. Review can be done either way: the private_registry_manage MCP tool's approve/reject actions, or the dashboard's Approve and Reject buttons, which call the same underlying check.

Versioning

Each skill ID and version pair can only be published once — republishing the same version is rejected outright, so a version can never be silently overwritten. Published content is capped at 2MB per version.

Deprecating a version (an admin-only action) marks it as no longer recommended without deleting it. Unlike approval, deprecation does hide a version by default: a deprecated version drops out of list, get, and install — any team member can still see it via list with the includeDeprecated option (this isn't restricted to admins), but get and install never surface a deprecated version, even by exact version number. See Governance for how deprecation fits into the broader lifecycle.