mcu-skills — Board-Specific MCU Agent Skills
Claude Code skills that give the model real board-level knowledge for STM32, ESP32, RP2040 and other MCUs, so it stops guessing pins and clocks.
- Source repo
- alexex1993/mcu-skills
- Stars
- ★ 20
- Last updated
- 4d ago
- License
- MIT
- Primary language
- C
- FA score
- 45/100 · Major gaps
At a glance
- How it runs
- Works with
- Platform-specificClaude Code
- Cost
- Free software; you pay for model usage
- Setup effort
- Low · running in minutes
- You'll need
- Typical use
- An engineer bringing up a WeAct MiniSTM32H7xx board who needs the right pin alternates and clock configuration before writing firmware.
- Not a fit if
- Developers who use Cursor, Copilot, or editors other than Claude Code
- Teams that need generic MCU knowledge rather than board-specific detail
- Anyone expecting bundled driver libraries or production-ready firmware
- Source review
- 45/100 · Major gaps
What does this agent do, and when should you use it?
mcu-skills is a collection of Agent Skills (SKILL.md) for embedded firmware work, organized one skill per physical board across STM32, ESP32/ESP8266, RP2040/RP2350, nRF52840, AVR and Baikal BE-U1000 families. Each directory under skills/<family>/<skill-name>/ holds the SKILL.md, a reference/ tree read on demand, a template/ project that actually builds, and assets/ with board photos and pinout images. It ships as a Claude Code plugin marketplace (.claude-plugin/marketplace.json, one plugin per skill) and as clone-and-install scripts (scripts/install.sh, scripts/install.ps1) that symlink or copy skills into ~/.claude/skills. Skills load automatically when you work on that board in Claude Code, or on demand via a slash command such as /stm32h750-weact. Authoring and review conventions live in docs/AUTHORING.md, docs/CHECKLIST.md and CONTRIBUTING.md; the license is MIT.
Each SKILL.md frontmatter plus body captures the board knowledge that otherwise sits in a datasheet, a reference manual, a schematic and a lost evening: which pin does what, which clock tree actually works, which HAL call silently does nothing, and how to get a build onto the chip. The body stays lean, deeper material is pushed into reference/ for on-demand reading, template/ provides a buildable project skeleton, and assets/ holds physical board photos with an IMAGE.md description. scripts/install.sh and scripts/install.ps1 offer --list, symlink (or a Windows junction) and --copy modes, all landing in one flat ~/.claude/skills/ namespace, so the skill directory name must equal the name: in frontmatter and be unique repo-wide. Through the plugin route, .claude-plugin/marketplace.json registers each skill as its own plugin whose name matches the skill.
- An engineer bringing up a WeAct MiniSTM32H7xx board who needs the right pin alternates and clock configuration before writing firmware.
- A developer building a firmware for the Waveshare ESP32-C6-Touch-LCD-1.47 who wants the display and touch pins stated correctly instead of inferred.
- A keyboard hobbyist writing a firmware for a nice!nano v2 clone (ProMicro nRF52840).
- Someone porting code between Raspberry Pi Pico (RP2040) and WeAct RP2350A and needing the differences spelled out.
- A maker on an Arduino Nano or an LGT8F328P MiniEVB who wants to avoid the usual flashing pitfalls.
- A team that wants to productize its board knowledge by authoring a new skill from the template and running it through the documented review bar.
How do you install or deploy this agent?
Install as a Claude Code plugin (the README's primary path):
/plugin marketplace add alexex1993/mcu-skills
/plugin install stm32h750-weact@mcu-skillsOn macOS / Linux, install from a clone:
git clone https://github.com/alexex1993/mcu-skills.git
cd mcu-skills
./scripts/install.sh --list
./scripts/install.sh stm32h750-weact # symlink into ~/.claude/skills
./scripts/install.sh stm32h750-weact --copy # or copy, if you want to edit locally
./scripts/install.sh --list # resultOn Windows, use the PowerShell script:
git clone https://github.com/alexex1993/mcu-skills.git
cd mcu-skills
.\scripts\install.ps1 --list
.\scripts\install.ps1 stm32h750-weact # junction into ~\.claude\skills
.\scripts\install.ps1 stm32h750-weact --copy # or copy, if you want to edit locally
.\scripts\install.ps1 --list # resultHow do you use this agent?
No further configuration is needed after install: the skill loads by itself when you work on that board in Claude Code. You can also invoke it explicitly in the session:
/stm32h750-weactFor a project-scoped install instead of user-scoped, copy the skill directory into .claude/skills/ inside your firmware project:
mkdir -p .claude/skills
cp -r skills/stm32/stm32h750-weact .claude/skills/The template/ folder inside the skill is a buildable starting project, and reference/ holds the deep detail the model reads when it needs it.
What are this agent's strengths and limitations?
- Covers 21 named boards from STM32H750 and ESP32-P4 to RP2350A and BE-U1000, organized per board rather than per chip, which matches how embedded debugging actually goes wrong.
- Every skill carries a buildable template/ project plus assets/ board photos and pinouts, so the model works from verifiable board facts.
- Ships .claude-plugin/marketplace.json, so skills install through the /plugin marketplace without hand-managing files.
- Cross-platform installer scripts (install.sh / install.ps1) support both symlink and copy modes, which matters when you want to edit a skill locally.
- MIT licensed, with AUTHORING.md, CHECKLIST.md and validate scripts defining the bar for new contributions.
- The core runtime is Claude Code and its Agent Skills mechanism; other editors or agent tools would need their own adapter for loading SKILL.md.
- All skills install into one flat ~/.claude/skills/ namespace, so names must be globally unique and will collide as the collection grows.
- Asset completeness varies: several rows in the skills table have an empty image column, so not every board has photos or pinout diagrams.
- It is knowledge and templates, not a driver library or firmware framework; builds still rely on each board's PlatformIO/Arduino toolchain.
- The cross-chip ESP32 comparison in skills/esp32/*/reference/esp32-family.md is adapted from third-party ESP32Features under CC BY 4.0, a different license from the MIT body.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| mcu-skills — Board-Specific MCU Agent Skills This agent | 45 · Major gaps | Agent plugin / skillFree + model costs | ★ 20 | 4d ago | C | Claude Code |
| Vibe Coding MVP Workflow | 74 · Some gaps | CLIFree + model costs | ★ 3.2k | 15d ago | TypeScript | Codex · Claude Code |
| Exort Embedded Workspace | 64 · Some gaps | Desktop appFree + model costs | ★ 226 | 22d ago | Svelte | — |
| ESP-Claw Edge Agent Framework | 37 · Major gaps | Framework | ★ 2.3k | today | C | OpenAI API · Claude API |
How does FollowAgents rate this agent?
Why each dimension lost points
The repository is a documentation/skill package (SKILL.md, reference, template) with no executable code, so the permission surface is inherently small. However, install scripts symlink or copy into ~/.claude/skills, and the README does not describe the scripts' permission boundaries, whether they write elsewhere, or any user confirmation or rollback. Data flow only notes skills auto-load in Claude Code; it does not describe which files the model reads or whether anything is sent externally. Dependency security only mentions that third-party code in template/lib keeps its own license; no dependency audit or version pinning. External effects (flashing firmware, DFU) are addressed in AUTHORING as a requirement to document recovery, but there is no repo-level rollback/recovery policy. Source attribution is solid: ESP32Features CC BY 4.0 adaptation and §11 attribution are explicit, and the MIT license is complete. Deductions: install-script permissions and rollback undocumented, dependencies unaudited, no sensitive-data handling statement.
README and AUTHORING are consistent on skill structure and naming rules (directory name == frontmatter name, globally unique), so self-consistency is good. Dependency availability only broadly requires templates to build on a clean machine, without listing toolchain versions or pinning. Failure messages: AUTHORING asks for symptom→cause→fix tables, but there is no repo-level error handling or diagnostics guarantee. Deductions: dependencies unpinned, failure messaging left to individual skills rather than guaranteed by the repo.
Audience and scenarios are clear (embedded firmware developers, per-board skills), and the description-writing guide emphasizes trigger-word coverage, so trigger precision is well designed. Capability boundaries have inclusion/exclusion principles but do not state what the skills will not do (e.g., not a datasheet replacement, no hardware-safety guarantee). Environment fit covers macOS/Linux/Windows installs but does not state Claude Code version requirements or compatibility with other toolchains.
Information architecture is clear (skills/<family>/<name> layout, docs, templates, scripts), and install notes are thorough (plugin marketplace, scripts, project-scoped install). Naming stability has explicit rules. Examples and FAQ are weak: only article links, no FAQ. Known limitations are only scattered mentions ('untested'), with no consolidated limitations list. License is complete (MIT). No version number or changelog. Maintenance responsibility is unclear (no maintainer role or issue process, only a contribution guide reference).
Output usability is good: templates are required to build as-is, recipes are copy-paste, and SKILL.md structure is specified, so usable scaffolds are directly produced. Marginal value is clear—board-specific trap knowledge is something general models lack. Cost-benefit: 20+ skills imply high maintenance cost, and no quality metrics or validation results are provided, so benefit depends on each skill's actual quality, which the repo cannot confirm.
claim_traceability: the README claims templates build and skills were validated on real hardware, but there are no test results or validation records in the repo, only process requirements in AUTHORING. cross_source_corroboration: external article links corroborate the project's existence, but there is no independent third-party verification. fact_inference_separation: AUTHORING asks authors to distinguish 'outside spec but works' settings, which is the right direction, but there is no repo-level labeling mechanism. Deduction: claims lack traceable evidence.
- Install scripts write symlinks or copies into ~/.claude/skills; the README does not describe their permission scope or uninstall/rollback, so review scripts/install.sh and install.ps1 before running.
- No dependency audit or version pinning is provided; third-party code under template/lib must be checked per skill for license and safety.
- The README claims templates build on a clean machine and skills were validated on real hardware, but there are no test records or validation evidence in the repo—these are unverified claims.
- No version number or changelog, making it hard to track changes to skill content over time.
- Publisher identity is not verified by the FollowAgents enterprise registry; maintenance responsibility and update path are unclear.