# Loadlynx User Operations > Operate LoadLynx hardware from an end-user machine through released host tools and official Web paths: install GitHub Release host tools with SHA256SUMS verification, use the released loadlynx/loadlynx-devd CLI surface as shipped, prefer saved devices and released CLI control flows, keep Web Serial as a formal human browser UI path, and do not fall back to source checkouts, raw local devd HTTP, or developer-only tooling. - Skill: `ivanli-cn/loadlynx-user-operations` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add ivanli-cn/loadlynx-user-operations` - Raw SKILL.md: https://api.skillmd.com/api/skills/ivanli-cn/loadlynx-user-operations/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: ivanli-cn (https://skillmd.com/u/ivanli-cn) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/ivanli-cn/loadlynx-user-operations --- # LoadLynx User Operations Use this skill on a normal user's computer. All skill-driven hardware operation must go through released `loadlynx` and `loadlynx-devd` binaries from GitHub Releases. ## Start Here - Install this skill with: ```bash npx skills add https://github.com/IvanLi-CN/loadlynx --skill loadlynx-user-operations -g ``` - Update this skill with: ```bash npx skills update loadlynx-user-operations -g ``` - Never require the user to clone the repository or install Rust, Bun, Just, `mcu-agentd`, `espflash`, or `probe-rs`. - Use only released LoadLynx host tools and released firmware assets from `https://github.com/IvanLi-CN/loadlynx/releases`. - Do not use the Web UI as the skill's agent-operated hardware path. Web Serial is a supported human browser path, not the default agent control path. - Before giving any CLI workflow, verify the installed program supports it: ```bash loadlynx --help loadlynx-devd --help loadlynx -v ``` - The current stable CLI surface should expose top-level commands such as `devices`, `device`, `status`, `status-stream`, `cc`, `cv`, `cp`, `pd`, `wifi`, `control`, `preset`, and `flash`. - `loadlynx-devd --help` must expose both `serve` and `bridge-http`. - If the requested workflow depends on a command that is absent, stop and report that the installed release does not support it. Do not invent commands, fall back to Web UI, or switch to source/developer instructions. ## Install Released Host Tools - Download the latest stable Release unless the owner explicitly accepts a prerelease. - Prefer the release installer script: - macOS/Linux: `install-loadlynx-host.sh` - Windows: `install-loadlynx-host.ps1` - The installer downloads the platform archive, downloads `SHA256SUMS`, verifies the selected archive hash, installs into a user-owned directory, validates the binaries, and prints PATH guidance. It must not edit shell startup files or PATH automatically. - If the installer fails in transport, switch to manual release-asset installation instead of silently continuing with an older binary. - If installing manually, choose the platform archive: - Apple Silicon macOS: `loadlynx-host-tools-macos-aarch64.tar.gz` - Intel macOS: `loadlynx-host-tools-macos-x86_64.tar.gz` - Linux x86_64: `loadlynx-host-tools-linux-x86_64.tar.gz` - Windows x86_64: `loadlynx-host-tools-windows-x86_64.tar.gz` - Manual installs must verify the archive against the release `SHA256SUMS` before extraction. - On macOS or Linux: ```bash mkdir -p "$HOME/.local/bin" tar -xzf "$HOME/Downloads/loadlynx-host-tools-.tar.gz" -C "$HOME/.local/bin" chmod +x "$HOME/.local/bin/loadlynx" "$HOME/.local/bin/loadlynx-devd" ``` - Verify after installation: ```bash loadlynx --help loadlynx-devd --help loadlynx -v ``` ## Connect Hardware - Connection priority is saved device first, then direct USB/LAN discovery. - Start the local daemon only when needed for long-running local USB sessions: ```bash loadlynx-devd serve ``` - The current `loadlynx` CLI auto-manages its local control path. Do not try to pass legacy daemon URL flags unless a future released CLI explicitly documents them again. - `loadlynx-devd bridge-http` is only for browser/Web/debug paths and must bind loopback only: ```bash loadlynx-devd bridge-http --bind 127.0.0.1:30180 ``` - Keep the bridge running while the browser uses it. Do not expose it on non-loopback interfaces. - Do not edit project-local caches or developer selector files by hand. ## CLI Device Memory - The CLI must be the source of remembered hardware. Do not rely on Web local storage, browser history, or project-local cache files for user workflows. - Use the current released device commands: ```bash loadlynx devices loadlynx device list loadlynx device add --name loadlynx device add --usb-port --name loadlynx device add --url http:// --name loadlynx device use loadlynx device use --global loadlynx device use --clear loadlynx device remove ``` - `loadlynx devices --json` and `loadlynx device list --json` expose the persisted device list plus the current global default. - `loadlynx device add --usb-port --name ` is the formal non-interactive path for saving a known USB serial port path. Use it in automation when the owner has specified the exact port. - `loadlynx device add` without extra selectors is interactive; in non-interactive automation it fails by design. Do not fake around that with manual JSON edits. - Prefer using a saved `--device ` target instead of repeatedly retyping hostnames or URLs. ## LoadLynx Business Workflows - Treat transport selection as preparation only. The user-facing job is operating the LoadLynx electronic load and PD sink safely through released CLI commands. - Identity and status: ```bash loadlynx devices loadlynx status --device loadlynx status-stream --device --interval-ms [--count ] --json loadlynx control get --device ``` - `loadlynx status --device --json` is the primary released read path for live telemetry, fault flags, link state, temperatures, voltage, current, power, and enable state. - `loadlynx status-stream --device --interval-ms --json` is the primary released continuous telemetry path for tests that need stable sample cadence. With `--json`, stdout is NDJSON: one compact JSON status sample per line for the whole sample stream. Diagnostics and final summaries belong on stderr, not stdout, so downstream collectors can parse stdout as pure NDJSON. - `loadlynx control get --device --json` reports the current mode, output-enabled state, active preset, and control snapshot. - Electronic-load control: ```bash loadlynx cc --device [--min-v-mv ] [--max-i-ma-total ] [--max-p-mw ] loadlynx cv --device [--min-v-mv ] [--max-i-ma-total ] [--max-p-mw ] loadlynx cp --device [--min-v-mv ] [--max-i-ma-total ] [--max-p-mw ] loadlynx cc --device --disable loadlynx cv --device --disable loadlynx cp --device --disable loadlynx control set --device --enable loadlynx control set --device --disable ``` - Use `--max-i-ma-total` and `--max-p-mw` as protection rails when running power tests. - USB-PD operation: ```bash loadlynx pd set --device --mode fixed --object-pos loadlynx pd set --device --mode pps --target-mv --i-req-ma ``` - Use `--allow-extended-voltage true|false` only when the user explicitly wants to cross the extended-voltage gate. - Presets: ```bash loadlynx preset list --device loadlynx preset set --device --file loadlynx preset apply --device ``` - Wi-Fi: ```bash loadlynx wifi show --device loadlynx wifi set --device --ssid --psk [--wait] loadlynx wifi clear --device ``` - Never echo PSKs or secrets in chat, logs, screenshots, traces, or shell history. - Wi-Fi writes must use an independent management path such as USB/devd. Do not use LAN HTTP, mDNS, a saved HTTP transport, "verified LAN", or an unsafe override to continue `wifi set` or `wifi clear`; bind/use USB/devd for the same device first. - Firmware: ```bash loadlynx flash digital --device --artifact loadlynx flash analog --device --artifact ``` - The default flash path is dry-run first; `--no-dry-run` is the real flash gate. - Real flash also requires `--confirm ` and `--acknowledge-non-project-firmware` when applicable. A successful flash command alone is not enough to claim the device is usable; verify identity and status afterward. ## External USB-C Source Validation - Use LoadLynx as a generic validation sink for external USB-C source devices without embedding another project's workflow into this skill. - Use a saved device target and prefer the saved USB/devd transport for operations that change LoadLynx state: ```bash loadlynx status --device --json loadlynx pd set --device --mode fixed --object-pos loadlynx pd set --device --mode pps --target-mv --i-req-ma loadlynx cv --device --max-i-ma-total --max-p-mw loadlynx cv --device --disable ``` - `loadlynx pd set` is the PD sink stimulus path. `loadlynx cv ` is the voltage-clamp load stimulus path for pushing a source device toward its current-limit or constant-current behavior. - For external current-limit validation, treat the external DUT's own diagnostics as the primary verdict. LoadLynx terminal voltage, current, power, and PD contract state are auxiliary cross-checks that help explain the stimulus and observed operating point. - A sink-side voltage drop during CV loading is not by itself a failure. If the external DUT reports that it is current-limiting as configured and has no relevant fault latch, the voltage drop can be expected evidence that the source entered constant-current regulation. - Always disable the LoadLynx output after the run and verify status before claiming the setup is restored. ## Download Released Firmware - Download firmware only from the chosen GitHub Release. - Prefer a release-provided firmware catalog such as `loadlynx-firmware-catalog-v0.5.1.json`, plus the firmware files referenced by that catalog. - Keep downloaded firmware and catalog files together in one user-owned folder so relative catalog paths can resolve. ## Web Serial - GitHub Pages and release Web bundles are supported human browser paths for identity, status, control, Wi-Fi, diagnostics, and flash only when the browser exposes Web Serial. - Web Serial saves identity/profile only and reconnects through browser-granted ports. It must not save OS port paths. - Unsupported browsers must guide the user to Chrome/Edge or the released CLI/devd tools. ## Escalate Out - Switch to `skills/loadlynx-developer-operations/SKILL.md` for source checkout, cloning, project builds, local devd builds, release workflow changes, probe or selector maintenance, HIL/debug sessions, or implementing missing CLI features. - If a hardware operation is only available through Web UI and not through released `loadlynx`, stop and escalate to developer work to add and release the CLI capability. - Do not use raw HTTP writes or source-tree commands to bypass missing released user functionality. ## Safety Checks - Before enabling output, changing sink mode, or flashing firmware, verify the selected device identity and target. - Treat command absence, link-down states, analog fault states, target mismatch, and hash mismatch as stop conditions. - After changing settings, flashing, or configuring Wi-Fi, verify status and reconnect behavior before claiming success.