// the find
zhinkgit/embeddedskills
An open-source collection of embedded development and debugging skills for Claude Code, Copilot, TRAE, and other AI coding assistants that support the Skill protocol. Once installed, the AI assistant can directly operate compilers, debuggers, and communication buses, automating the full workflow from code generation to hardware verification.
A collection of Python-based skill plugins that let AI coding assistants (Claude Code, Cursor, etc.) directly drive embedded toolchains — Keil, GCC/CMake, J-Link, OpenOCD, probe-rs, serial ports, CAN buses — instead of just generating code you then compile yourself. The closed-loop idea is real: AI writes code, triggers a build, reads the compiler error, fixes it, flashes the device, reads the GDB output, all without you copy-pasting between windows. Aimed at firmware engineers already using one of the supported AI coding tools.
The workflow orchestrator (`workflow` skill) does genuine work: it auto-detects project type and chains build → flash → debug in one AI-driven pass, which removes a real friction point in embedded dev. The unified JSON output format across all scripts (`status`, `summary`, `details`, `next_actions`) is a smart contract — it gives the AI consistent signal to act on rather than scraping freeform CLI output. Tool coverage is surprisingly broad: Keil MDK (still dominant in RTOS/automotive shops), CMake/GCC, three debug probes, CAN-FD, and network capture all in one install. The `npx skills add` one-liner works on an existing project with zero changes to build files.
Almost everything is Windows-only in practice — Keil MDK is Windows-only, the Wireshark/tshark dependency for `net` requires Npcap (Windows), and the screenshots all show Windows Terminal. Linux/Mac embedded devs (who mostly run OpenOCD + probe-rs just fine) will hit walls. CAN skill is marked 'pending test' and `terminal` is 'pending hardware test', so two of the most interesting skills aren't validated yet. The configuration layer (three JSON files plus CLI args) is underdocumented — `runtime-resolution-spec.md` exists but the config schema isn't surfaced in a way that makes it easy to know what you actually need to set for a given board/probe combo. There's no mechanism to sandbox or audit what commands the AI actually runs on your machine, which is a real concern when you're letting an AI invoke `JLink.exe` with write-memory commands on production hardware.