Skip to content
Docs
DocumentationCommand reference

Command reference

v0.0.4Revision 587c8ae

These examples use the pinned scoped package through npx, so they work without a global installation. Choose Windows for the npx.cmd form; the terminal choice stays synchronized across these guides.

Help

Section titled “Help”
Terminal window
npx --yes @npmmo/roster@0.0.4 --help

No subcommand, help, and --help display usage. --version is not implemented. Do not use it to identify an existing installation.

Init

Section titled “Init”
Terminal window
npx --yes @npmmo/roster@0.0.4 init --no-dense

Discovers client configurations, imports server definitions, merges default skill sources, and prints a receipt. It does not rewrite client configs.

  • --no-dense skips the optional embedding-runtime question.
  • --dense requests runtime installation without asking interactively.
  • Without those flags, an interactive terminal can offer the optional runtime; a non-interactive run does not wait for an answer.

Neither declining nor --no-dense changes an existing embeddings setting. See source-build lexical setup.

Receipt

Section titled “Receipt”
Terminal window
npx --yes @npmmo/roster@0.0.4 receipt

Re-discovers current configs and updates the local receipt. Synced clients report their routed server inventory rather than counting the Roster proxy as a backend. It includes skill counts and review findings. Token estimates are labeled; it is not a measured universal savings report.

The saved receipt includes local config paths. Do not share it unredacted.

Sync

Section titled “Sync”
Terminal window
npx --yes @npmmo/roster@0.0.4 sync --client cursor

--client accepts claude-code, cursor, codex, or openclaw. Without it, sync attempts all four. Each client selects its first existing candidate config. Unknown client IDs are rejected.

Backups precede config writes. A URL-only server causes a pre-mutation refusal. See client setup.

Eject

Section titled “Eject”
Terminal window
npx --yes @npmmo/roster@0.0.4 eject --client cursor

Uses the same four --client IDs, or attempts all four when omitted. Restores every active path in that client’s backup era.

--force explicitly selects pristine bytes and can replace newer edits. It is not a safe default, does not waive integrity checks, and does not make moved symlinks safe. Normal live-state restoration preserves later changes at key level.

Serve

Section titled “Serve”
Terminal window
npx --yes @npmmo/roster@0.0.4 serve

Runs a local stdio MCP server. --five or --transparent overrides the configured mode for that process. Without a flag, the config applies; its default is transparent.

The client normally launches this process from the synced entry. --http is not implemented. Learn the routing modes before changing them.

Dense

Section titled “Dense”
Terminal window
npx --yes @npmmo/roster@0.0.4 dense status
Terminal window
npx --yes @npmmo/roster@0.0.4 dense enable

dense without a subcommand means status. It executes a bounded local backend probe without downloading model weights. READY identifies a usable native or WASM backend; it does not mean a model is warm or configuration permits embeddings. enable installs or reconciles the optional runtime, then resolves and verifies it in a fresh process, including after repair. When native bindings cannot load, the local WASM worker supports the verified Alpine/musl and Intel macOS cases. There is no disable subcommand; use the embeddings config field. Dense retrieval details.

Telemetry

Section titled “Telemetry”
Terminal window
npx --yes @npmmo/roster@0.0.4 telemetry status

telemetry defaults to status. on records local consent; off clears it. No event builder or upload endpoint exists at this revision, including when consent is on. Privacy details.

Unquarantine

Section titled “Unquarantine”
Terminal window
npx --yes @npmmo/roster@0.0.4 unquarantine filesystem__read_text_file

Clears local drift quarantine for the provided capability ID. Review the change first. This is not certification and does not run a suite.

Combine run

Section titled “Combine run”

This self-contained example requires a Roster source checkout and must be run from its repository root: the suite and fixture files are not included in the npm package. It is a synthetic fixture, not a real vendor benchmark:

Terminal window
npx --yes @npmmo/roster@0.0.4 combine run suites/filesystem/tasks.yaml --name local-fixture -- node packages/combine/test/fixtures/fake-fs-server.mjs "{{sandbox}}"

The shape is combine run <suite.yaml> --name <label> -- <command> [args]. Optional --out <path> changes the default lab-results.json output path. The marker {{sandbox}} is replaced with the per-task sandbox path.

This starts the specified server and executes the suite’s calls. Use a fresh working area and an authorized test server, not personal production data. The fixture above is intentionally synthetic and does not earn a named League rank.

Exit behavior

Section titled “Exit behavior”

Successful finite commands exit 0. A failed sync or refused eject exits nonzero; multi-client operations isolate failures and can leave some clients completed while others failed. serve remains attached to its stdio transport. A Combine run succeeds only when all its tasks pass.

Dashboard, bench, Wrapped, receipt percentiles, roast, automatic failover, and combine self remain planned. They are not hidden CLI commands.

Exact command parser