Embedded AI Harness — скилл
Скиллы Claude Code и стенд на Raspberry Pi: агент пишет прошивку для ESP32, прошивает плату и гоняет тесты на железе до зеленого
- 277 ★ репозитория
- Последний коммит
- MIT
Широкий доступ
Почему такой уровень
- Агент прошивает физические платы, перезагружает их и управляет сетью стенда, поднимая тестовую точку доступа WiFi
- Установка на Raspberry Pi запускается от root и ставит службы, правила udev и сетевые демоны
- Сборки идут через GitHub Actions и `gh`, то есть агент пушит код и получает артефакты из вашего аккаунта GitHub
Установка
- Работает в
В терминале, через SkillFoxx CLI
npx skillfoxx add skills/embedded-ai-harnessОпределит агенты на машине, покажет уровень доступа и зафиксирует версию.
Другие способы установки
Доступ и проверки
Как мы проверяемШирокий доступИнструмент может менять данные, выполнять команды или работать с секретами.
- Агент прошивает физические платы, перезагружает их и управляет сетью стенда, поднимая тестовую точку доступа WiFi
- Установка на Raspberry Pi запускается от root и ставит службы, правила udev и сетевые демоны
- Сборки идут через GitHub Actions и `gh`, то есть агент пушит код и получает артефакты из вашего аккаунта GitHub
Это чужой код. Посмотрите файлы в репозитории перед установкой.
Что делает
Embedded AI Harness замыкает цикл разработки прошивок: агент пишет код, собирает, прошивает настоящую плату ESP32, проверяет работу по WiFi, MQTT, BLE и радиоканалу, читает ошибки и правит. Остановка наступает, когда тесты зеленые. Спецификация задает, что считать готовым, тесты выводятся из нее и выполняются на железе. Метод оформлен четырьмя скиллами Claude Code по фазам: `/define` готовит функциональную спецификацию с проверяемыми требованиями, `/harness` один раз настраивает проект (документы, план тестов, хуки в прошивке, CI), `/commission` проверяет, что плата и партнеры рабочие, `/build` ведет цикл. Каждая фаза заканчивается шлюзом, который вычисляется по состоянию проекта. Релиз выпускается тегом git, после чего собранный в контейнере артефакт проверяется на стенде. Стенд собирается из Raspberry Pi 3, 4 или 5 (либо Zero 2 W с USB-хабом и Ethernet-адаптером), на нем работает служба с HTTP API. В отдельных скиллах описаны ESP-IDF, PlatformIO, логирование, WiFi, BLE, MQTT, отладка, RF и CI. Весь API стенда доступен как 70 инструментов MCP. Прошивка собирается в GitHub Actions в зафиксированном контейнере, локально ESP-IDF и PlatformIO ставить не требуется.
Для кого. Разработчикам встраиваемых систем на ESP32, которые хотят доверять написанной агентом прошивке, потому что она проверена на реальной плате.
Подходит, если
- Нужно описать новое устройство одной фразой и получить прошивку, которая прошла тесты на железе
- Баг проявляется только на плате, а агент не видит ни загрузку, ни логи
- Для проверки нужны реальные WiFi, MQTT, BLE и радиообмен, а не симулятор
- Требуется воспроизводимая сборка: прошивается артефакт из CI, а не локальный бинарник
- Несколько плат в слотах стенда надо использовать с удаленной машины или из контейнера разработки
Не подходит, если
- Нет Raspberry Pi и платы ESP32: без стенда агенту нечем проверять прошивку
- Проект не на ESP32 или не на ESP-IDF и PlatformIO: набор тестов и скиллы рассчитаны на эту экосистему
- Нет аккаунта GitHub и настроенного gh: сборка идет через GitHub Actions
- Нужно прошить плату вручную один раз: достаточно esptool
Пример запроса к агенту
/define: датчик температуры на ESP32 публикует измерения в MQTT каждые 10 секунд и переживает потерю WiFi. Составь спецификацию и план тестовОграничения
- Нужен стенд: Raspberry Pi с WiFi и Bluetooth, плата ESP32 в слоте. Радиоприемник RTL-SDR, генератор Si5351 с PE4302 и провода к выводам EN и BOOT не обязательны.
- Прошивка собирается в GitHub Actions, поэтому нужны аккаунт GitHub, `git` и авторизованный `gh`. Агент и стенд должны находиться в одной сети.
- На Pi Zero 2 W с 512 МБ памяти без предварительной защиты от нехватки памяти плата падает под нагрузкой, а жесткие сбои портят SD-карту.
- MCP-интерфейс покрывает не весь HTTP API стенда, часть функций доступна только через HTTP и скиллы.
Как отключить. Удалите скопированные папки из `.claude/skills/` проекта. Службу стенда на Raspberry Pi остановите командой `sudo systemctl stop` с именем службы портала и при желании удалите ее. Установленные скриптом зависимости (hostapd, dnsmasq, mosquitto и другие) снимаются средствами системы пакетов Pi.
Частые вопросы
Как поставить скиллы Embedded AI Harness в Claude Code?
Установите Claude Code командой `npm i -g @anthropic-ai/claude-code`, затем скопируйте папку `.claude/skills/` из репозитория в свой проект. После этого доступны `/define`, `/harness`, `/commission` и `/build`.
Нужно ли ставить ESP-IDF или PlatformIO на компьютер?
Нет. Сборка идет в GitHub Actions в контейнере с зафиксированной версией, `gh run download` скачивает артефакт, и его прошивают на стенде. Скиллы умеют собирать и локально, но цикл от этого не зависит.
Как собрать стенд?
Подготовьте Raspberry Pi с Raspberry Pi OS Lite 64 бита, клонируйте репозиторий и выполните `sudo bash install.sh` в папке `pi`. Скрипт поставит зависимости и запустит службу портала, а `curl http://$BENCH:8080/api/devices` покажет подключенные платы.
Можно ли управлять стендом из Claude Desktop?
Да. MCP-сервер дает 70 инструментов, а для Claude Desktop есть пакет `mcp/embedded-ai-harness-testbench.mcpb`, который перетаскивают в Settings, Extensions и вводят адрес стенда.
Кто выпускает релиз?
Человек. Тег версии остается единственным шагом без агента: после него релиз собирается в контейнере и проверяется на стенде.
Обсуждение
Вопросов и отзывов пока нет.
Похожие
Скиллы24 скилла для прошивок микроконтроллеров: сборка, прошивка, отладка GDB, UART, Modbus, CAN, логические анализаторы и статанализ
Embedded Skills
embeddedskills
Скиллы для встраиваемой разработки: ИИ управляет компиляторами, отладчиками (J-Link и др.) и шинами (CAN), от кода до проверки на железе. README на китайском
Плагин Claude Code с навыками /readiness и /setup оценивает готовность проекта к работе агентов и ставит правила и проверки.
Больше двадцати скиллов для кодовых агентов: MCP и хуки, режим плана, протокол багфикса, промпты и защитный хук для bash
Одиннадцать скиллов для Claude Code и Codex: аудит тестов, очистка git worktree, страницы планов, расшифровка записей экрана и вход через 1Password
Скиллы команды Codely ведут работу агента по фазам: план в файле или GitHub Issues, ревью после каждой фазы и аккуратный коммит
Коротко о README
README сравнивает разработку с агентом без обратной связи и замкнутый цикл по аналогии с системой управления. Дальше идут пять шагов пути от определения до выпуска со шлюзами, состав набора, список требований, устройство стенда на Raspberry Pi, сборка стенда, примеры HTTP и Python, управление из Claude, поиск неполадок и ссылки на документацию.
Бейдж для README
Исходный 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.