Read-only triage of a live, misbehaving tesla-key-esp32 board — pull GET /status and GET /diag, read heap / link_state / WiFi / BLE / MQTT / pairing, and match the symptom to a KNOWN failure signature. Use when asked to "diagnose the device", "what's wrong with the board", "the device is broken/unreachable", "check the device health", "pull /status", "read the diag log", "why can't evcc reach it", "BLE won't connect / connect error 13", "MQTT stopped publishing", "OTA says the image is invalid / signature bad", "it's boot-looping", "it lost its pairing", or to triage a board before deciding whether to reflash. STRICTLY read-only and cache-only: never wakes the car, never sends a command; it diagnoses and hands off (it does not itself flash or command the car).
Render the on-device ST7735 display simulator to PNG state montages so a human can eyeball "does it look right?" after touching the presenter/renderer. Use when asked to "preview the display", "render the display states", "show the display", generate the display montage/simulator images, check the on-device panel layout, or after editing main/logic/display_model.hpp or main/display.cpp (landscape 160x80 / portrait 80x160, SoC gradient, RSSI bars, SSID scroll, WiFi/BLE search + Pairing animation). Read-only, python3 stdlib only — no board, no ESP-IDF, no Docker. This is the VISUAL check that complements the automated presenter↔sim parity gate.
Verify the ALREADY-PUBLISHED OTA release channel is internally coherent so real devices can actually update — fetch the GitHub Pages manifest, assert version/build/offset coherence, and confirm every per-target image URL the firmware pulls is reachable (read-only — gh + curl + jq, plus one optional live-device GET). Use when asked to "verify the OTA channel", "is OTA healthy", "can devices update", "check the OTA manifest", "check the release channel", after a release lands on main, when a device reports "signature bad" or an OTA image 404s, or to confirm the manifest version / per-target images / embedded version stamp all agree. Scope is the published channel only — for a build + USB-flash use the flash-esp32 skill, for merge → CI → flash use the ship skill.
Comprehensive, whole-project coherence review of the tesla-key-esp32 firmware — finds bugs, inconsistencies, doc/code drift, config/build mismatches, and cross-cutting incoherence so docs, code, config and the build all agree and the project is correct. Use whenever the user asks to "review the project", "project review", audit the repo, "check docs/code for errors/inconsistencies", check that everything is consistent/coherent, or after a batch of changes to make sure nothing drifted. Reach for this even when they don't say "review" — any "is the whole thing still right/coherent?" request fits.
Dedicated drift audit of every skill AND agent under .claude/ against the tesla-key-esp32 project — confirms each still maps the code/config/scripts that exist and corrects any that contradicts them, in place. This is the PR-gated skills-coherence check (require-skill-audit.sh blocks opening a PR and every push to it until it has run against the current tree). Use whenever you ask to "check the skills", "audit the skills/agents", "are the skills still in sync / complete", "did a skill drift", after changing anything under .claude/ or after a batch of code changes, or before opening/pushing a PR. Narrower and faster than project-review (which audits the whole firmware and gates the merge); skill-audit is the skills/agents subset — a full /project-review also satisfies this gate.
Emergency, no-build USB recovery of a tesla-key-esp32 board that is bootlooping or refuses every OTA — reflash the already-published, SIGNED CI image to the app slot and erase otadata WITHOUT wiping NVS (pairing / key / VIN / WiFi survive). Use when asked to "recover", "unbrick", "de-brick", "rescue" or "resurrect" a board, when OTA reaches 100% then fails "signature bad" / "downloaded image is invalid" (the running image's TOFU trust anchor was signed with a key ≠ the published images), when the device is stuck in a boot/reboot loop after flashing an unsigned local build, when a normal reflash or OTA won't bring it back, or when the board reports the wrong/old version and refuses every update. User-only — it flashes physical hardware. For the normal build-and-flash path use flash-esp32; for merge → CI → flash use ship.
Take the current PR all the way to the board in one step — merge (squash), watch the post-merge CI build on main, download the SIGNED per-target image, USB-flash it (NVS/pairing preserved) and verify the device reports the new version; or trigger OTA instead when no cable is attached. Use when asked to "ship", "ship it", "merge und flash", "merge and flash", "release this to the board", or after a PR is approved and the change should end up running on the device. For a quick local-tree build+flash WITHOUT merging, use the flash-esp32 skill instead.
Build and USB-flash the tesla-key-esp32 firmware (ESP32 / S3 / C3 / C6 / C5) over the serial port. Use when asked to "flash", "flashe", "flash the device", deploy firmware/web-UI changes to the physical board over USB, or reflash after editing main/. Defaults to esp32s3; set TARGET for other chips. Auto-detects the serial port and preserves NVS (pairing/key/VIN). For pull-based OTA updates instead, see docs / the web UI version tap.