Administer your organization

Manage members and roles in SkillHub, issue and scope API tokens, and audit everything.

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.

The CLI isn't on skillhub-cli yet, so the skillhub binary comes from your own build. Commands here are real and run against whichever registry your config points at, and the dashboard URLs the CLI prints open the real dashboard. Everything below is accurate to the shipped CLI — where a capability is dashboard-only, this guide says so.

Where each surface owns the work

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

Task	Dashboard	CLI
See your orgs and your role in each	yes	`skillhub org` `list`
Invite a person to a registry with a role	yes	`skillhub registry` `invite`
Set a registry's default org role	yes	— (dashboard only)
Create an API token	yes	`skillhub token` `create`
List / revoke API tokens	yes	— (dashboard only)
Read the audit log	yes	— (dashboard only)
Confirm who you're signed in as	yes	`skillhub whoami`

The CLI is thin on purpose: it exists for the from-scratch journey and for CI. Everything beyond it lives on the dashboard.

Step 1 — Know who you are and what you administer

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

Confirm the authenticated identity

skillhub whoami proves your stored credential actually works — it verifies against the server, not just that a credential exists — and shows where the credential came from and which registry URL is in effect:

skillhub whoami

@pat (Pat Rivera)
registry: https://registry.example.com (project)
token: from the OS keychain

The token: line names the source — the SKILLHUB_TOKEN environment variable, the OS keychain, or the credentials file — so you always know which credential is answering. With --json you also get the server-side tokenId (non-null when you're authenticated with an API token), which is what you'd cross-reference against the tokens list in the dashboard.

List the orgs you belong to

skillhub org has exactly one subcommand — list — and it shows every org you belong to alongside your org role in each:

skillhub org list

@studio  owner
@acme    member

Org roles are owner, admin, and member. list is the whole of org management in the CLI by design; inviting people, changing roles, and setting registry defaults happen on the dashboard.

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 dashboard home for a signed-in administrator, the entry point into an organization's registries, members, and settings.

The Members screen lists everyone in the org with their org role, and is where you invite people and change roles:

The organization Members screen: a roster of members with their org roles (owner, admin, member) and controls to invite a person or change a member's role.

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.

Role-based access with org-inherited defaults plus per-registry grants: the registry's default sets the baseline for all org members, and an explicit grant on a registry always overrides the inherited default for that one user. So a registry can default members to reader while a named collaborator is granted publisher directly.

Grant per-registry access

Setting a registry's default org role is a dashboard action. Granting one person access to one registry works from either surface.

Open the org's registry and use its access controls to invite a GitHub handle or email with a registry role. The org's registries are namespaced under it — for example @studio/design-systems:

An organization's registry page showing the registry under the org namespace, where an admin manages access grants and the default org role.

skillhub registry invite grants a registry role to a GitHub handle or email. The role is one of reader, publisher, or admin:

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

The command issues a one-time redemption link and prints it once — share it with the invitee. An argument containing @ is treated as an email; anything else is a GitHub handle. See the registry CLI reference for the full --json shape (invite plus its inviteUrl).

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:

The organization Settings screen: the org's display name and handle, and the org-level configuration an owner or admin manages.

Only owners and admins can change org settings and membership. A member inherits registry access through defaults but doesn't administer the org — which is exactly what skillhub org list shows you next to each org.

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:

The API tokens settings screen: a list of tokens each showing its name, read/publish scopes, expiry, and a revoke control.

Create a token

skillhub token create mints a token. It requires a --name and a comma-separated --scopes list; valid scopes are read, publish, and admin. Scope it to only what the pipeline needs — a read-only install token takes just read:

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

To confine a leaked CI token to a single registry, restrict it with --registry:

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

Scope	Grants
`read`	Resolve and install skills.
`publish`	Publish versions and move dist-tags.
`admin`	Administrative actions, including promotion on review-required registries.

A token's full secret is shown exactly once — at creation — and never again; the server stores only a hash, so it can't be re-displayed. A live token looks like skh_live_ followed by 32 characters. Scope it tightly (only the scopes and, where possible, the single registry it needs), keep it in a secret store, and revoke it from the dashboard the moment it leaks. Listing and revoking tokens are dashboard-only — the CLI creates tokens, it doesn't manage them.

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.

The organization audit log: a chronological trail of administrative events — member and role changes, token creation and revocation, and publish and promotion activity — each with the actor and timestamp.

The audit log is read-only and lives only on the dashboard — there's no CLI command that reads or writes it. It's the record you consult after a token leak or a disputed role change to see exactly what happened.

Administer your organization

Where each surface owns the work

Step 1 — Know who you are and what you administer

Confirm the authenticated identity

List the orgs you belong to

Step 2 — Manage members and roles

How roles resolve

Grant per-registry access

Step 3 — Configure organization settings

Step 4 — Issue and scope API tokens

The token settings screen

Create a token

Use a token for auth

Step 5 — Audit everything

Where to go next

Organizations & roles

API tokens

org reference

token reference

registry reference

whoami reference

On this page