Organizations & roles

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 with GitHub OAuth, and every user also gets a personal namespace (e.g. @pat) for registries they own themselves.

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 list

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

Inviting members

Invite a GitHub handle or email to a registry with a role:

skillhub registry invite @studio/design-systems freya --role publisher

Roles for an invite are reader, publisher, or admin.

The CLI covers the essentials — listing your orgs and inviting people to a registry. Most org and member administration lives on the dashboard.