Administer your organization

An organization is a shared workspace — a common namespace, a set of registries, and a way to grant a whole team access at once. Administering one is mostly a dashboard flow: you invite people, set roles, issue and revoke API tokens, and read the audit trail there. The CLI covers the from-a-terminal essentials — seeing your orgs and roles, granting per-registry access, minting tokens for CI, and confirming who you're authenticated as.

This guide walks the whole administrative loop across both surfaces. If you want the model behind it first — org vs. registry roles, inherited defaults, and explicit grants — read Organizations & roles; this page is the hands-on walkthrough.

Where each surface owns the work

Administration is split deliberately. A quick map before the walkthrough:

The CLI is thin on purpose: it exists for the from-scratch journey and for CI. Almost everything beyond it lives on the dashboard — the one exception is the last row, and it is worth understanding before you plan around it.

Step 1 — Know who you are and what you administer

Before changing anything, confirm your identity and the orgs you can act in.

skillhub whoami

@pat (Pat Rivera)
registry: https://skillhub.fyi (default)
token: from the OS keychain

skillhub org list

@studio  owner
@acme    member

Step 2 — Manage members and roles

Open the org on the dashboard to manage people. From the terminal, jump straight there — skillhub open with no ref lands on your dashboard home, and skillhub open @owner opens that org's page:

skillhub open @studio

The Members screen lists everyone in the org with their org role, and is where you invite people and change roles. Invite by email address or GitHub handle. Every invitation issues a one-time redemption link, shown to you once, and an email invitee is also mailed the invitation. The confirmation names what actually happened rather than assuming delivery — that the message went to the address, or that none was sent and why — and the link is valid either way. A GitHub-handle invitee has no address to mail, so there the link is the delivery.

Screens only an owner or admin can use say so plainly to everyone else: the org's audit log names the role required rather than showing an empty table, and it is hidden from the sidebar for members who cannot open it.

How roles resolve

Access lives at two levels — the organization and the individual registry — and org access flows down to the org's registries by default.

• Org roles: owner, admin, member.
• Registry roles: reader (install), publisher (publish and tag), admin (administer the registry, including promoting versions).

Each org-owned registry carries a default org role (defaultOrgRole) — the registry role every org member gets automatically. It can be none, reader, publisher, or admin. On top of that baseline you can grant a specific person a role on a single registry directly.

Grant per-registry access

Setting a registry's default org role is a dashboard action. Giving one person a registry role splits by who they are: the dashboard adjusts the role of someone already in the org, and the CLI invites someone who isn't yet.

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

Step 3 — Configure organization settings

The org's Settings screen is where the org's display name, handle, and other org-level properties live. This is a dashboard-only surface — there is no skillhub command that edits org settings:

Step 4 — Issue and scope API tokens

Interactive login uses the browser device flow, but automation can't open a browser. For headless and CI use, issue API tokens — scoped, long-lived credentials you hand to a pipeline. This is the one administrative area where the CLI does the creating and the dashboard does the managing.

The token settings screen

The dashboard's token settings list every token with its scopes, expiry, and last use — and it's the only place to revoke one:

Create a token

skillhub token create --name ci --scopes read,publish

✓ created token ci (scopes: read,publish)
skh_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
This is the only time the token is shown — store it now (the server keeps only a hash).

skillhub token create --name ci --scopes publish --registry @studio/design-systems

Use a token for auth

Once created, a token authenticates automation two ways:

• login --token stores it like any other credential (OS keychain, falling back to a 0600-mode file):

  skillhub login --token skh_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

• The SKILLHUB_TOKEN environment variable — set it in CI and skip the login step entirely. It takes effect with nothing stored on disk and stays active even after skillhub logout. skillhub whoami reports token: from the SKILLHUB_TOKEN environment variable when it's in play, so you can confirm CI is using the token you think it is.

For the complete scope table, per-registry restriction, and --json payload, see API tokens and the token CLI reference.

Step 5 — Audit everything

Administrative actions are recorded. The org's audit log is a durable, dashboard-only trail of who did what and when — member and role changes, token creation and revocation, publishes, and promotions on review-required registries. Nothing about an administrative action is silent.

Where to go next