FAQ

No. Everything SkillHub writes locally is gitignored by default, so working in a client-owned repo never adds stageable files — git status stays clean. skillhub init writes a managed .gitignore block covering the project config directory and every agent skills directory it links into, and later commands extend that block when a fan-out reaches an agent directory it doesn't yet cover. Opt out with --no-gitignore if you really want to: no install, sync, update, or remove will then create a block you declined. (Re-running a plain skillhub init will, though — that command's whole job is to write it, and the decline isn't remembered in config. Pass --no-gitignore again.)

By default, skills install once into a canonical store and fan out by symlink into each agent's skills directory. Copy is the fallback, never the default: it kicks in automatically on platforms without symlinks (with a notice), or when you ask for it with --copy. Copied skills show as copyMode: true in skillhub list. One practical difference: a copy in an agent skills directory is rebuilt from the store on every sync that touches the skill, so edit the skill in the store — that's where edits are protected.

Yes — edit it in the store: .skillhub/skills/<name>/ in the project scope, or the same path under your home config directory for the global scope. Each install records a content baseline for that directory, so the CLI knows your copy carries changes: skillhub list shows it as modified, a sync at the same version leaves it byte-for-byte alone, and a run that would replace or delete it asks first — or refuses with STORE_MODIFIED when it has no way to ask. Run skillhub sync --discard-modified to put the published content back, or skillhub sync --publish to send your edits the other way — up to the registry the skill came from, as the next version. Full details in sync.

• Project scope installs into the repo you're in (the project config directory at the repo root) — this is the default.
• Global scope installs into the machine (your home config directory) and is selected with --global / -g on scope-aware commands.

Use project scope for skills a repo needs; use global scope for skills you want everywhere on your machine.

Pin to an exact version so it never moves without an explicit action:

skillhub install @studio/design-systems/tokens-workflow@1.2.0 --pin

A range (like @^1.2.0) or a dist-tag (like @beta) tracks a channel instead; --pin freezes to the exact version. Pinned skills are held in place by skillhub update and reported in its pinnedHeld list.

Visibility is a registry-level property (private or public), set when you create the registry — not something you choose per publish. There's deliberately no publish --access; set visibility with registry create --visibility or on the dashboard:

skillhub registry create design-systems --visibility private

There aren't any. To change what's installed, use skillhub install, skillhub remove, skillhub update, and skillhub sync. Linking is an internal implementation detail — skills fan out to agents by symlink automatically, with a copy fallback — so there's nothing to link by hand.

Two pieces: authenticate with a token, and reconcile with a frozen lockfile.

skillhub login --token <api-token>
skillhub sync --frozen

sync --frozen fails (exit 1) if the lockfile would change, so CI catches an out-of-date lockfile instead of silently drifting. You can also skip the login step by setting the token environment variable directly in your pipeline. See API tokens.