Universal-Embedded-Workbench

Drive the Universal Embedded Workbench's RTL-SDR receiver over `/api/sdr/*` — decode/analyze/power captures, the phased `acquire`, the interactive live rtl_433 console, "AI Sherlock" record→reverse-engineer, USB recovery, and the rtl_433 device database. Use this whenever the user wants to receive, sniff, decode, analyze, or reverse-engineer an RF signal (433/315/868 MHz remotes, sensors, TPMS), read RSSI/pulse timing, recover a wedged dongle, or add a device to rtl_433 — even if they only say "rtl_433", "rtl-sdr", "sniff a remote", "what frequency is this", "signal too strong", "no signal", "AI Sherlock", or "add this remote". This is the receive-side counterpart to the transmit-only `signal-generator` skill. Always GET `/api/sdr/status` first to confirm the dongle is detected.

Complete PlatformIO lifecycle: build, upload, and monitor ESP32 firmware. Automatically detects whether a workbench is available or the device is connected locally via USB. Covers platformio.ini configuration, RFC2217 remote upload, environment selection, and serial monitor. Triggers on "pio", "platformio", "pio run", "pio upload", "platformio.ini".

Generates or updates a Functional Specification Document (FSD) for any kind of system — embedded, cloud back-end, mobile, networking, SDR, or hybrid. Converts rough project descriptions into structured FSDs with requirements, test cases, and traceability. Supports initial generation and incremental evolution, and loads optional domain packs (e.g. ESP32) for domain-specific detection and test libraries. Triggers on "FSD", "fsd", "write FSD", "create FSD", "generate FSD", "new FSD", "update FSD", "evolve FSD", "functional spec", "specification document".

Design FSD-driven functional test cases with bidirectional traceability — every spec clause maps to ≥1 test, every test claims the source lines it exercises (via `@fsd` tags in the code), and an optional coverage check verifies those lines actually ran. Produces test spec documents, a machine-readable traceability matrix, and a gap report (orphaned clauses / orphaned tests / orphaned code). Use when the user wants to build a test suite from an existing FSD, audit whether existing tests cover an FSD, generate a traceability matrix linking spec ↔ test ↔ code, or close gaps between documented behavior and tested behavior. Triggers on "design test cases from FSD", "trace tests to code", "build traceability matrix", "FSD coverage tests", "test coverage of spec", "functional coverage audit", "trace FSD".

Integrates an ESP32 project with the Universal ESP32 Workbench. Adds firmware modules (UDP logging, WiFi provisioning, OTA, BLE command handling, strategic log messages), updates build config, then writes the Workbench operations, Testing, and Appendix chapters into the project's existing FSD. Triggers on "integrate workbench", "add workbench", "workbench integration", "set up project", "add testing", "add tester".

Manipulate ESP32 DUT during automated tests using the Serial Portal and WiFi Tester infrastructure. Covers serial reset/monitor, NVS erase, captive portal triggering, and WiFi AP provisioning. Use when running tests, resetting the DUT, entering captive portal, provisioning WiFi, or monitoring serial output. Triggers on "test harness", "reset DUT", "captive portal test", "provision WiFi", "NVS erase", "clean state", "test setup".

Drive the Universal Embedded Workbench's RF signal generator over `/api/siggen/*` — continuous carrier, Morse/CW beacon, retune, PE4302 attenuation, and frequency listing. Use this skill whenever the user wants to emit, key, retune, or attenuate an RF signal from the workbench, even if they only say "CW beacon", "carrier", "Morse", "Si5351", "GPCLK", "PE4302 attenuator", "DF test", "direction finder", or "80m beacon" — those are all this one API. Always check `/api/siggen/status` first to see which backend (Si5351 vs GPCLK fallback) and attenuator are physically present before choosing a backend.

Remote GDB debugging of ESP32 devices via the workbench. Covers USB JTAG (C3/S3), dual-USB (S3 two-port), and ESP-Prog (FT2232H) approaches. Use when setting up JTAG debugging, connecting GDB, configuring OpenOCD, or troubleshooting debug connections. Triggers on "GDB", "JTAG", "debug", "OpenOCD", "breakpoint", "ESP-Prog", "step through", "debug session".

Complete ESP-IDF lifecycle: project setup, build, flash, monitor, and OTA. Automatically detects whether a workbench is available or the device is connected locally via USB. Covers sdkconfig, partition tables, esptool, RFC2217 remote flashing, GPIO download mode, OTA updates, crash recovery, and flapping. Triggers on "flash", "build", "upload", "idf.py", "monitor", "serial console", "slot", "workbench", "esptool", "OTA", "erase", "download mode", "crash loop", "flapping", "bricked", "menuconfig", "set-target", "sdkconfig", "partition".

Use this skill whenever the user needs to interact with BLE peripherals through the workbench — scanning for devices, connecting by address, writing to GATT characteristics, or checking connection status. The Pi acts as a BLE-to-HTTP bridge using bleak. Also use when sending keystrokes to BLE HID devices, triggering OTA via BLE commands, or debugging BLE connectivity. Triggers on "BLE", "bluetooth", "GATT", "NUS", "Nordic UART", "BLE scan", "BLE write", "BLE connect".

Use this skill whenever you need to read serial output or debug logs from ESP32 devices on the workbench. Covers serial monitor with pattern matching (wait for boot messages, WiFi connected, crash dumps), UDP debug log retrieval when USB is occupied (e.g. HID keyboard), boot capture, and crash analysis. Use for verifying firmware started correctly, checking WiFi connection status, or diagnosing boot loops. Triggers on "serial monitor", "log", "debug log", "UDP log", "boot output", "crash", "monitor", "pattern", "serial output".

Use this skill whenever tests involve MQTT communication — starting/stopping the mosquitto broker on the workbench Pi, publishing test messages, subscribing to topics, or verifying ESP32 MQTT client behavior. The broker runs on the Pi's WiFi AP network (192.168.4.1:1883) so DUTs can reach it without internet. Use for MQTT integration tests, pub/sub verification, and broker lifecycle management. Triggers on "MQTT", "broker", "mosquitto", "publish", "subscribe", "topic", "MQTT test".

Use this skill whenever running automated tests that need progress tracking on the Pi's web UI, or when a test step requires physical operator action (button press, cable swap, power cycle). Covers test session lifecycle (start/step/result/end), human interaction requests with blocking modal on the Pi display, and activity log queries. Use for any test workflow that an operator needs to follow visually. Triggers on "test progress", "test session", "human interaction", "operator", "activity log", "test tracking", "test panel".

Use this skill whenever you need to control the workbench's WiFi radio for testing — starting a SoftAP for DUTs to connect to, joining a DUT's captive portal as a station, scanning for networks, relaying HTTP requests to devices on the WiFi network, or provisioning DUT WiFi credentials. Essential for any test that involves WiFi connectivity, captive portal flows, or HTTP communication with devices on the isolated test network (192.168.4.x). Triggers on "wifi", "AP", "station", "scan", "provision", "captive portal", "enter-portal", "HTTP relay", "wifi test", "SoftAP".