sno-cli

Sno CLI

sno is one binary. This file carries the rules, the task map and the recipes. The exact commands and flags of the version that is installed are served by the binary itself, so they cannot be out of date.

Start Here

Choose the executable once and keep using it:

• Use the absolute path the installer printed.
• Otherwise run type -a sno (works in bash and zsh). If two sno files are listed, or the version is older than the installer said, tell the owner, use the newer absolute path, and note that a running shell may need hash -r or a new terminal.
• If sno is not installed, say so. Do not look for its source.

In every command block, sno stands for that absolute executable. Then read the reference for this exact version, once:

sno --version
sno

sno alone prints the list of commands. Before you use a command, read sno <command> --help (for a nested command, sno <group> <command> --help). That output comes from the installed binary, so it is the authority for every flag.

Conventions

• Pass --json when you parse the output. Stdout is then exactly one JSON value.
• A command you typed incompletely or inexactly is completed, or answered, instead of failing:
  • Unique prefixes of subcommands and flags work: typing sno stat runs sno station.
  • A missing value gets a default, and a note says which (notes in JSON, the first line in text).
  • When nothing sensible can run, you get guidance: a JSON object with "usage": true and "executed": false, or full help plus an example, and the exit code is 0. A normal result has no executed field; a missing executed means the command ran.
• After a command that is meant to change something, read the result before you tell the owner it worked. A value that does not match is not applied: for example sno station consent with a misspelled level only shows the current level and a note, and the exit code is still 0. Check that the returned value is the one the owner chose, and that executed is not false.
• A real failure keeps a non-zero exit code and its message says what to do next. Report that message to the owner; do not retry in a loop.
• Anything that changes the machine is run only when the owner asked for it.

Sno GPU attribution

When a Sno command invokes Sno GPU, keep the real project/session/run context in the command's supported inputs; read its installed help before choosing flags or JSON fields. For RSI, sno rem judge already accepts a run with per-session project context and sno rem recall accepts project_id. Do not relabel a mixed-project run as the shell's current repository, invent attribution flags, or call GPU/Helicone directly to bypass Sno.

The component sending GPU HTTP must supply its own repository slug as X-Sno-Source, the stable feature workload (rsi for RSI) as X-Sno-Workload, and a fresh UUID v4 as X-Request-ID generated inside every attempt, including retries, never in static client headers. New repositories and workloads need no registration or approval. The sender must record status or failure with that ID and preserve existing operation IDs. Authentication/admission supplies verified user and machine identities; never add caller-supplied user/machine identity headers. Missing diagnostic context is recorded as unknown without rejecting valid model work. These rules also apply to future GPU-backed commands; the full caller contract is in the skill library's skills/README.md. Other model providers and health/model-list probes keep their own behavior.

Task map

Flags are not listed here on purpose; read them from sno <command> --help.

Recipes

Report a fresh install to the owner

sno --version
sno doctor --json
sno skills core

Tell the owner the version, where it is installed, and the one next step. Station onboarding questions and product offers are put to the owner as questions; you never answer them.

Check health

sno doctor --json
sno project status --json
sno usage --json

doctor exits 0 on warnings. Read the rows whose result is failed or missing and relay each with its fix. If usage says the machine is not registered, tell the owner and offer sno account register.

Update

Never ask the owner to run sno update. Any sno command that finds the CLI or an installed product older than the latest release (checked once a day) updates first and then runs what was asked. sno update exists for manual use only.

Uninstall

sno uninstall
sno uninstall sno-station
sno uninstall sno-station --yes

The first two only list and explain; nothing is removed. Uninstalling is the one action that is asked about even when the owner just told you to do it, the same way rm -rf is: a request such as "uninstall sno-station" is not the confirmation. Run the first two, show the owner what will be removed, ask "Uninstall now?", and stop. Run the third only after the owner answers yes in a later message. If there is no later message, your answer is the plan and the question. --purge-state also deletes Reach mail state; ask for that separately.

Local REM jobs

sno station rem-start --type noop --scope persona:demo
sno station rem-status --wait --timeout 60

rem-status without an id reads the most recent job started on this machine.

Owner-only actions

Ask the owner, and wait for the answer, before you:

• set a telemetry consent level (sno station consent <level>) or pause or resume it;
• record an answer to a product offer (sno products <product> <answer>);
• send a human verdict on a REM judgment (sno rem verdict);
• run sno uninstall … --yes, or --purge-state — even when the owner's own request was to uninstall.

Reading is always fine: sno station consent with no value, sno products with no arguments (it lists), doctor, usage, skills, project.