Organizations & roles
Shared workspaces, org and registry roles, inherited defaults, and how explicit grants override them.
An organization is a shared workspace — for example @studio. It gives a
team a common namespace, a set of registries, and a way to grant access to
everyone at once. Members join an org with a role, and by default that access
flows down to all of the org's registries.
You sign in by continuing with GitHub or with an email address and password, and
every user also gets a personal namespace (e.g. @pat) for registries they own
themselves. You can belong to several organizations at once and switch between
them in the dashboard — accepting an invitation into a new one never costs you
access to one you already had. (How many orgs you can create is a plan limit;
how many you can be a member of is not.)
Two levels of roles
Access is expressed at two levels: the organization and the individual registry.
Org roles
Every member of an org holds one org role:
- owner — full control of the org.
- admin — administers the org and its registries.
- member — belongs to the org and inherits registry access via defaults.
See the orgs you belong to and your role in each:
skillhub org listRegistry roles
Access to a specific registry is expressed with registry roles:
- reader — can install from the registry.
- publisher — can publish and tag (subject to any review policy).
- admin — can administer the registry, including promoting versions.
Inherited defaults, overridden by explicit grants
Each org-owned registry has a defaultOrgRole — the registry role that org
members receive automatically. For example, a registry might set
defaultOrgRole: publisher, meaning "org members are publishers here." The
default can be none, reader, publisher, or admin.
An explicit grant on a registry overrides the inherited default for that
user. So a registry can default org members to reader, while a specific
collaborator is granted publisher directly.
An explicit registry grant always wins over the inherited default for that user — the default sets the baseline, and a direct grant overrides it.
Inviting members
The normal way to bring someone onto a team is to invite them to the organization, from the dashboard's Members screen. They join with an org role, and the org's registries then resolve for them through the defaults above — one invitation, access to everything the org shares.
For the narrower case — granting one registry to somebody who is not in the org, such as an outside collaborator on a single client project — invite them directly to that registry with a registry role:
skillhub registry invite @studio/design-systems freya --role publisherRoles for a registry invite are reader, publisher, or admin. Accepting it
creates a grant on that registry alone; it does not add the person to the
organization, and they see nothing else the org owns.
Registry-scoped invitations are CLI-only for now — the dashboard invites to the organization. See Administer your organization for which surface owns what.
An invitation has two independent routes to its recipient. Every invitation produces a one-time redemption link, shown once, for you to hand over yourself. An invitation addressed to an email address is additionally mailed to it. A GitHub handle has no address to resolve, so for those the link is the only delivery.
Because the two are independent, the result reports what the mail actually did — sent, skipped, rate-limited, or failed — rather than assuming it worked. The invitation is recorded before any mail is attempted, so the link is valid whatever the answer.
The CLI covers the essentials — listing your orgs and inviting people to a registry. Most org and member administration lives on the dashboard.