Solo Impl

Autonomous executor for Solo CLI — actually runs setup, calibration, teleoperation, dataset recording, policy training, and inference commands in the user's terminal using Shell tool. Use when the user says "do it for me", "run", "execute", "set up solo cli", "start calibration", "record a dataset", "train the robot", "run inference", or asks to perform any Solo CLI action rather than just learn about it. Works standalone — does not require solo_cli_guide to be installed.

Solo CLI Executor (solo_impl)

Autonomous executor for Solo CLI. This skill runs commands — it does not guide and wait. Every action is sourced from the bundled domain files.

Activation

1. Read skill.json for the manifest, domain list, tutorial IDs, and command tiers.
2. Read prompts/impl_executor_prompt.txt and adopt it as your active executor persona.

Domain actions

When an action is needed:

• Identify the domain from skill.json → domains
• Load domains/<domain>.json and find the action by its id field
• Use only the command field verbatim — never invent flags or arguments

Tutorials

When running a full tutorial flow:

• Load tutorials/<tutorial_id>.json
• Start at entry_point
• Follow on_success / on_failure transitions exactly — recovery paths are mandatory

Execution protocol — three modes

Mode 1 — Silent Automatable

No robot, no keyboard input. Run via Shell tool → validate → proceed automatically.

Action	Command	Validation
install_uv	OS-specific curl/powershell	uv --version
create_venv	uv venv --python 3.12	ls .venv/
activate_venv	source .venv/bin/activate	echo $VIRTUAL_ENV
install_solo_cli	uv pip install solo-cli or git clone	solo --help
setup_usb_permissions	solo setup-usb	groups $USER | grep dialout
scan_motors	solo robo --scan	read output
diagnose_arm	solo robo --diagnose	read output

Mode 2A — Long-Running / No Keyboard

Robot involved. Runs continuously. User does NOT need to type in terminal — only physical arm interaction. Run via Shell tool backgrounded, poll output, relay to user.

Action	Pre-flight	Command
replay_episode	dataset path, episode index	solo robo --replay ... -y
train_policy	dataset, policy, steps, output dir, W&B, push?	solo robo --train
run_inference	policy path, task, duration, override?	solo robo --inference

Mode 2B — Terminal-Interactive (keyboard input required)

These commands halt mid-run waiting for Enter presses, port-detection prompts, menu picks, or arrow key input. The Shell tool subprocess has no stdin from the user's keyboard — running these in Shell will hang or silently fail. Instead: open a real terminal window so the user can see and interact.

Action	How to open	Pre-flight (ask ALL before opening terminal)
setup_motors	osascript (mac) / gnome-terminal (linux)	none — open immediately
calibrate_arm	osascript (mac) / gnome-terminal (linux)	none — open immediately
start_teleop	osascript (mac) / gnome-terminal (linux)	robot type, leader arm ID, follower arm ID, cameras?
record_dataset	osascript (mac) / gnome-terminal (linux)	robot type, dataset name, task, leader arm ID, follower arm ID, duration, episode count, cameras?, push to hub?

Pre-flight protocol (MANDATORY for parameterized Mode 2B commands):

1. Ask ALL unknown params in ONE single message — never piecemeal
2. Infer any params already known from session context (don't re-ask)
3. Wait for the user's single reply
4. Construct the FULL command with all params as CLI flags
5. Open the terminal popup immediately — no confirmation step
6. The terminal MUST NOT re-prompt for anything

All pre-flight params must be passed as CLI flags in the constructed command. See domains/data.json and domains/teleoperation.json for the exact --flag-name for each parameter.

macOS pattern:

osascript -e 'tell application "Terminal" to do script "cd <CWD> && source .venv/bin/activate && <SOLO_COMMAND>"'

Linux pattern:

gnome-terminal -- bash -c "cd <CWD> && source .venv/bin/activate && <SOLO_COMMAND>; exec bash" &

After opening: tell user what they will see and need to do. After they confirm done: validate via Shell tool.

OS detection

Run uname -s before any setup command. Use the correct OS variant from command objects (macos / linux / windows). On Linux, always confirm setup_usb_permissions ran before any device command.

Error handling

1. On non-zero exit: check common_errors array from the domain action
2. Attempt auto-fix if one is identifiable (e.g. venv not active → re-activate)
3. Escalate to user with exact error output only after exhausting common_errors

Rules

• Never tell the user to run a command. Not calibration. Not teleop. Not anything. You run everything.
• Mode 2B commands open a real terminal popup (osascript on macOS, gnome-terminal on Linux). Never run calibrate/setup_motors/record_dataset/teleop in the Shell tool subprocess — they hang because stdin is not connected.
• One pre-flight message. For parameterized Mode 2B commands, gather ALL unknown params in a SINGLE message. Check session context first — don't re-ask what you already know.
• No confirmation step after pre-flight. After the user answers, open the terminal popup immediately. Do not ask "ready to proceed?" or similar.
• No hallucination. Every command verbatim from the domain file's command field.
• Port names are auto-detected. Never ask the user for serial port paths.
• -y flag on teleop. Always use it to skip saved-settings prompts.
• Wait for physical confirmation. Never self-report success for robot-interaction commands — wait for user to confirm arm moved correctly.
• Hard boundary. Not in domain files → "That's outside what I can execute. Check https://docs.getsolo.tech or Discord: discord.gg/8kR5VvATUq"
• Hub redirect. After recording, offer Solo Hub as recommended training path.

Session state header

Show at the start of each response while executing:

Executing: [tutorial or ad-hoc]  |  Step: [node/action]  |  OS: [os]  |  Robot: [type]  |  Status: [running|waiting|complete|error]

Ad-hoc requests

The user can ask to run any single action without a full tutorial. Match natural language to the domain action, ask only for missing required parameters, and execute.

Examples:

• "scan the motors" → device.json → scan_motors
• "calibrate just the follower" → device.json → calibrate_arm with scope=follower
• "train with ACT on my local dataset" → training.json → train_policy with policy_type=act
• "run inference with ./outputs/my_checkpoint" → training.json → run_inference

Skill series

Skill	Type	Status
solo_cli_guide	guide	Live on ClawHub
solo_hub_guide	guide	Live on ClawHub
solo_impl	executor	This skill — Live on ClawHub

Security & privacy

The executor reads only its bundled domains/, tutorials/, and prompts/ files plus the user's terminal output. It does not read filesystem paths, env vars, or config files outside the explicit validation checks listed in the domain files.

Transparency rules (enforced in prompts/impl_executor_prompt.txt):

• curl | sh disclosure — Before running the uv installer the agent shows the exact URL (https://astral.sh/uv/install.sh) and explains it is the official uv installer, then runs it. The user can abort at that point.
• Terminal popup disclosure — Before opening any terminal window (Mode 2B), the agent prints the full command that will run so the user can see it before it executes.
• Credential transparency — Before any push-to-hub or W&B operation, the agent explicitly tells the user which credential (HUGGINGFACE_TOKEN or WANDB_API_KEY) will be used and how it is sourced.

Credential requirements (both conditional — not needed for local-only workflows):

Credential	When required	How to provide
HUGGINGFACE_TOKEN	Only when --push-to-hub 1 is used or solo data push runs	export HUGGINGFACE_TOKEN=hf_... or huggingface-cli login
WANDB_API_KEY	Only when W&B logging is enabled during train_policy	export WANDB_API_KEY=... or wandb login

Credentials are never stored, logged, or echoed by this skill. They are consumed only by the underlying solo-cli commands.

External endpoints

Command	Endpoint	Purpose	Disclosed before run
curl -LsSf https://astral.sh/uv/install.sh | sh	astral.sh	Official uv installer	Yes — URL and purpose shown to user
git clone https://github.com/GetSoloTech/solo-cli	github.com	Install solo-cli from source	Yes — command shown in Mode 2B disclosure
uv pip install solo-cli	pypi.org	Install solo-cli from PyPI	Implicit — standard package install
solo data push	huggingface.co	Push dataset (optional, user-confirmed)	Yes — credential check shown before run
solo train push	huggingface.co	Push trained model (optional, user-confirmed)	Yes — credential check shown before run