Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/org-quicko/skillset/llms.txt

Use this file to discover all available pages before exploring further.

The Skillset CLI (skillset) is the primary tool for publishing, searching, and installing Skills from any Skillset Registry. This page walks through installing the CLI, connecting it to a Registry, and confirming the connection is working.

​
Install the CLI

The CLI is published to npm as @in-org-quicko/skillset-cli. Install it globally to get the skillset binary on your PATH, or invoke it without installing via npx. 
npm install -g @in-org-quicko/skillset-cli
All examples on this page and throughout the CLI documentation assume a global install. If you are using npx, replace every skillset with npx @in-org-quicko/skillset-cli.

​
Authenticate against a Registry

Every Registry requires a Token for write operations (publishing). Read operations — searching, browsing, and installing — work without a Token, but you still need to tell the CLI which Registry to talk to. Mint a Token from the Registry’s web interface (your profile → Tokens), then run:
1

Run the login command

skillset login --registry <url>
The CLI prompts you for your Token interactively. The Token is masked so it never appears in your shell history or process table.
2

Verify the session

skillset whoami
The CLI prints your email address, role, and the Registry URL it is authenticated against.

​
Pass the Token on the command line

If you need to suppress the interactive prompt — for example, in a script that still uses the stored config file — pass --token directly: 
skillset login --registry https://skills.example.com --token <secret>
Passing a Token as a CLI flag exposes it in your shell history and the OS process table. For unattended environments prefer environment variables — see CI & Automation.

​
Plain-HTTP Registries

By default the CLI refuses to send a Token over a plain http connection to any host that is not on your local machine, because the Token would travel unencrypted on every subsequent call. Loopback addresses (localhost, 127.0.0.1, ::1) are exempt. If your Registry is genuinely deployed on plain HTTP (not recommended for production), pass --insecure: 
skillset login --registry http://registry.internal --token <secret> --insecure

​
Stored configuration

After a successful login the CLI writes the Registry URL and Token to a per-user config file. The path follows OS conventions:
PlatformDefault path
Linux / macOS$XDG_CONFIG_HOME/skillset/config.json (or ~/.config/skillset/config.json)
Windows%APPDATA%\skillset\config.json
The file is written with mode 0600 (owner-read/write only) to protect the stored Token. You can override the path with the SKILLSET_CONFIG_PATH environment variable.
Environment variables SKILLSET_REGISTRY and SKILLSET_TOKEN always override the stored config file. This is the recommended approach for CI and automation — no login step required. See CI & Automation for details.

​
Verify your session

skillset whoami
The CLI resolves your identity from the Registry and prints:
  • Your email address and role
  • The Registry URL the session is authenticated against
If no Registry is configured at all, whoami exits with an error directing you to run skillset login or set SKILLSET_REGISTRY.

Build docs developers (and LLMs) love

Get started for freeTalk to us