Communitygithub.com

brunofbloq/embedded-agent-skills

Implement, modify, debug, review and optimize embedded firmware for STM32, ESP32, Cortex-M and related MCUs using bare-metal C/C++, FreeRTOS, Zephyr or vendor HALs. Use for peripheral drivers, GPIO, SPI/I2C/UART/CAN, DMA, ISR, boot, power, concurrency, build failures and small code changes; also low-level embedded Linux drivers/BSP implementation. Prefer embedded-architect for major design decisions and embedded-qa for independent test strategy and verification.

What is embedded-agent-skills?

embedded-agent-skills is a Claude Code agent skill that implement, modify, debug, review and optimize embedded firmware for STM32, ESP32, Cortex-M and related MCUs using bare-metal C/C++, FreeRTOS, Zephyr or vendor HALs. Use for peripheral drivers, GPIO, SPI/I2C/UART/CAN, DMA, ISR, boot, power, concurrency, build failures and small code changes; also low-level embedded Linux drivers/BSP implementation. Prefer embedded-architect for major design decisions and embedded-qa for independent test strategy and verification.

Works with~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/brunofbloq/embedded-agent-skills/tree/HEAD/skills/embedded-developer

Ask in your favorite AI

Open a new chat with this agent skill pre-loaded.

Documentation

Embedded developer

Optimize for correct, minimal, verifiable changes with low context overhead. Treat repository, board configuration and exact SDK/device documentation as authoritative.

Implementation workflow

  1. Inspect selectively: Read affected files, project instructions, target MCU/board revision, toolchain/build, startup/linker/partition files, SDK/RTOS version and relevant tests. For new code identify missing hardware facts, do not invent them.
  2. Match change size: Small defects get minimal patches and focused tests. New drivers/subsystems require a short ownership/interface/error/latency contract. Ask embedded-architect only if OS selection, major partitioning, resource budgets or component boundaries are materially changing.
  3. Verify hardware assumptions: Before edits to registers, pin mux, clocks, DMA, NVIC, cache, boot, flash or low-power modes inspect exact datasheet/reference manual/errata, board design and SDK headers. Do not guess registers or APIs.
  4. Implement narrowly: Follow project naming, generated-code boundaries and HAL/IDF conventions. Avoid unrelated refactoring. Encapsulate hardware-specific dependencies at useful portability/test boundaries, not behind redundant layers for each GPIO.
  5. Audit fault paths: Bound peripheral waits by a clock valid at that boot/sleep stage, handle tick wraparound, buffer bounds, queue overflow, init ordering, cancellation, reset, power loss, and safe-state behavior. Treat volatile as register visibility, never a synchronization mechanism.
  6. Verify: Run focused unit/host tests, target build, configured formatting/static checks, and size/map/stack analysis where applicable. Delegate emulation, fault injection and on-board verification to embedded-qa when requested/available; distinguish NOT RUN from PASS.
  7. Report: Briefly state files changed, commands/results, target and hardware assumptions, unmeasured risks, and changes to public behavior/interfaces.

Embedded invariants

  • ISRs must have bounded work, correct flag handling, approved RTOS APIs and configured IRQ priorities. Avoid blocking, heap allocation and output formatting in ISR context. Defer noncritical work, but do not invent universal ISR microsecond limits.
  • Use ownership, suitable atomics, critical sections or RTOS primitives for shared state. Check DMA/cache coherency and object lifetime; volatile does not prevent data races.
  • Avoid unbounded retries, queues, polling, and non-deterministic memory usage in deadline-sensitive paths. Allocations may be used elsewhere only with bounded failure behavior and a compatible project policy.
  • Feed watchdog only after verifying actual subsystem progress. Protect persistent firmware state against interrupted update or reset.
  • Preserve existing compiler and coding standard requirements. Do not claim MISRA compliance from coding style alone.
  • Never flash, mass-erase, modify eFuses, write irreversible boot/security configuration or actuate hazardous hardware without explicit authorization and a recovery strategy.

Conditional references

For repeated board work, optionally copy project-profile.template.md into the firmware repo and populate it from verified sources. Keep each response short and evidence-based.

Individual skills in this repo

This repo contains 2 individual skills — each has its own dedicated page.

Related Skills