Embedded AI Harness skill
Claude Code skills and a Raspberry Pi testbench: the agent writes ESP32 firmware, flashes the board and tests it on hardware
- 277 ★ on the repository
- Last commit
- MIT
Broad access
Why this level
- The agent flashes physical boards, resets them and controls the bench network, raising a test WiFi access point
- The Raspberry Pi install runs as root and adds services, udev rules and network daemons
- Builds go through GitHub Actions and `gh`, so the agent pushes code and downloads artifacts from your GitHub account
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add skills/embedded-ai-harnessDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewBroad accessThe tool can change data, run commands or handle secrets.
- The agent flashes physical boards, resets them and controls the bench network, raising a test WiFi access point
- The Raspberry Pi install runs as root and adds services, udev rules and network daemons
- Builds go through GitHub Actions and `gh`, so the agent pushes code and downloads artifacts from your GitHub account
This is third-party code. Review the repository files before installing.
What it does
Embedded AI Harness closes the firmware development loop: the agent writes code, builds, flashes a real ESP32 board, checks behavior over WiFi, MQTT, BLE and radio, reads the failures and corrects them. It stops when the tests are green. The specification defines what counts as done, and the tests are derived from it and run on hardware. The method comes as four Claude Code skills by phase: `/define` produces a functional spec with verifiable requirements, `/harness` sets up the project once (docs, test plan, firmware hooks, CI), `/commission` proves the board and peers work, `/build` drives the loop. Each phase ends at a gate computed from project state. A release is cut with a git tag, after which the artifact built in a container is verified on the bench. The bench is built from a Raspberry Pi 3, 4 or 5 (or a Zero 2 W with a USB hub and an Ethernet adapter) running a service with an HTTP API. Separate skills cover ESP-IDF, PlatformIO, logging, WiFi, BLE, MQTT, debugging, RF and CI. The whole bench API is available as 70 MCP tools. Firmware is built in GitHub Actions in a pinned container, so a local ESP-IDF or PlatformIO install is not required.
Who it is for. Embedded developers on ESP32 who want to trust agent-written firmware because it was verified on a real board.
Good fit when
- You want to describe a new device in a sentence and get firmware that passed tests on hardware
- A bug shows only on the board and the agent sees neither the boot nor the logs
- Verification needs real WiFi, MQTT, BLE and radio traffic, not a simulator
- You need a reproducible build: the CI artifact is flashed, not a local binary
- You want to use several boards in the bench slots from a remote machine or a dev container
Not a fit when
- You have no Raspberry Pi and no ESP32 board: without a bench the agent cannot verify firmware
- The project is not ESP32 or not ESP-IDF and PlatformIO: the test set and skills target that ecosystem
- You have no GitHub account and no configured gh: the build runs through GitHub Actions
- You just need to flash a board by hand once: esptool is enough
Example request
/define: an ESP32 temperature sensor publishes readings to MQTT every 10 seconds and survives a WiFi loss. Write the spec and the test planLimitations
- A bench is required: a Raspberry Pi with WiFi and Bluetooth and an ESP32 board in a slot. An RTL-SDR receiver, an Si5351 with PE4302 and wires to the EN and BOOT pins are optional.
- Firmware is built in GitHub Actions, so a GitHub account, `git` and an authenticated `gh` are needed. The agent and the bench must be on the same network.
- A Pi Zero 2 W with 512 MB runs out of memory under load without prior hardening, and hard crashes corrupt the SD card.
- The MCP interface does not cover the whole bench HTTP API, and some functions are available only through HTTP and skills.
How to disable. Delete the copied folders from the project's `.claude/skills/`. Stop the bench service on the Raspberry Pi with `sudo systemctl stop` and the portal service name, and remove it if you like. Dependencies the script installed (hostapd, dnsmasq, mosquitto and others) are removed with the Pi's package manager.
FAQ
How do I install the Embedded AI Harness skills in Claude Code?
Install Claude Code with `npm i -g @anthropic-ai/claude-code`, then copy the `.claude/skills/` folder from the repository into your project. `/define`, `/harness`, `/commission` and `/build` then become available.
Do I need ESP-IDF or PlatformIO on my computer?
No. The build runs in GitHub Actions in a container with a pinned version, `gh run download` fetches the artifact and it is flashed on the bench. The skills can build locally too, but the loop does not depend on it.
How do I build the bench?
Prepare a Raspberry Pi with Raspberry Pi OS Lite 64-bit, clone the repository and run `sudo bash install.sh` in the `pi` folder. The script installs dependencies and starts the portal service, and `curl http://$BENCH:8080/api/devices` lists connected boards.
Can I drive the bench from Claude Desktop?
Yes. The MCP server exposes 70 tools, and for Claude Desktop there is a `mcp/embedded-ai-harness-testbench.mcpb` package that you drag onto Settings, Extensions and enter the bench URL.
Who ships the release?
A human. The version tag stays the only step without the agent: after it the release is built in a container and verified on the bench.
Discussion
No questions or reviews yet.
Related
Skills24 skills for microcontroller firmware: build, flash, GDB debugging, UART, Modbus, CAN, logic analyzers and static analysis
Embedded Skills
embeddedskills
Skills for embedded development: AI drives compilers, debuggers (J-Link and others) and buses (CAN) from code to hardware checks. README in Chinese and English
A Claude Code plugin with /readiness and /setup skills that scores a repo for agent work and installs rules, hooks and checks.
Over twenty skills for coding agents: MCP and hooks, plan mode, a bug-fix protocol, prompting and a bash safety hook
Eleven skills for Claude Code and Codex: test audit, git worktree cleanup, plan pages, screen recording transcripts and 1Password sign-in
Codely team skills that run agent work in phases: a plan in a file or GitHub issues, review after each phase and a clean commit
README in short
The README contrasts agent development without feedback with a closed loop, using a control-system analogy. It then covers the five-step path from definition to release with gates, the toolkit contents, the requirements list, the Raspberry Pi bench design, building the bench, HTTP and Python examples, driving it from Claude, troubleshooting and documentation links.
README badge
Original SKILL.md
--- name: build description: > Phase 3 of AI Closed-Loop Programming — the Build phase, and the driver of the whole loop: locate the project on the chain, name the next act, design and declare tests, dispatch code/flash/verify, correct until the tests run clean. Owns the test plan, test design, audit, reconcile, and the change-request procedure. Use this skill whenever the user wants to build or continue building a harnessed project, asks "what's next" or "where are we", wants a feature added (change request), mentions test design, the test plan, xfail, audit, coverage gaps, reconciling drifted code, or "run the loop" — and for Phase 2 work when invoked via /commission. --- # Build — the loop's driver (Method skill) **AI Closed-Loop Programming**: open-loop AI coding generates and hopes; AICLP feeds back reality — the code runs on real hardware, tests derived from the FSD measure it against the spec, the error corrects the next iteration. The loop exits at zero: tests green. | Control loop | Here | |---|---| | Setpoint | The FSD — what must be true | | Plant | Firmware on the real chip | | Sensor | Tests derived from the FSD, run on the testbench | | Error signal | Failing tests | | Controller | The AI, correcting until error = 0 | This skill drives Phases 2 and 3 of the journey. `/commission` and `/build` are two doors into it; the phase is **derived from state, never chosen by the command typed**. Each phase ends at a **gate** — not a milestone. A milestone is a marker you pass; a gate has to open, and it can send you back. Every gate is **derived, never declared**, and every one is *checked*: the owning skill states its deliverables and the check that opens it. > **Run the check in a fresh checker that did not author the work** — the > project's generated gate file plus the repo, nothing else, and **never > memory or a summary of the session's own work** (`references/gate-checks.md`). **If any requirement of the gate is unmet, > name it, loop back to the step that owns it, fix it, and re-run the whole > check with a new checker** — not only the part that failed. Never carry a > known deficiency forward, and never enter a phase whose predecessor's gate > is still shut.