About library-selection
A skill for developers selecting firmware libraries for a specific board and software stack. It checks provenance, compatibility, dependencies, and resource impact, then validates a pinned choice with compile and behavior checks.
Key features
- 01Check upstream source, release, and license
- 02Assess architecture and framework compatibility
- 03Review dependencies, resources, and hardware assumptions
- 04Pin a version and record rationale
- 05Validate with compile and behavior checks
Use cases
- 01Select a library for a board and framework
- 02Assess memory and bus impact
- 03Verify dependency versions and runtime behavior
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ wedsamuel1230/ embedded-engineering-skills --skill library-selectionAfter installing, type/library-selectionin Claude Code to confirm it loaded.
Details
From the project READMELibrary Selection
Treat a library as part of the firmware and hardware contract. A popular package that compiles for one architecture may still use incompatible pins, timers, memory, bus assumptions, or APIs on another.
Intake
Record exact board/module, architecture, Arduino core or vendor SDK, compiler, toolchain, required API, bus/pin constraints, memory budget, license boundary, update policy, and whether the device is connected or field-updatable.
Process
- Find the upstream source, release/tag, license, supported architectures, and framework instructions. Prefer primary repositories and current release notes.
- Compare candidate API fit, board variants, transitive dependencies, flash/ SRAM/heap impact, blocking behavior, concurrency, bus/pull-up assumptions, and error/recovery behavior.
- Check open issues and maintenance signals without treating stars or install count as compatibility proof.
- Select a pinned version, record provenance and rationale, and document unsupported board/framework branches.
- Run a minimal compile fixture, then a simulated or target behavior check.
Anti-rationalization
| Shortcut | Response |
|---|---|
| "It has many installs." | Verify architecture, core version, API, and hardware contract. |
| "The newest version is best." | Read release notes, compatibility, footprint, and regression history. |
| "The I2C scanner found it." | Test library initialization, register reads, timing, and error paths. |
| "It worked on AVR." | Recheck ESP32/S3/Pico architecture, pins, timers, and memory. |
| "The dependency is only a helper." | Include transitive code and license/security review. |
Verification
- Candidate comparison contains source, version, architecture, and license.
- Minimal compile output names the exact FQBN/environment and dependency resolution.
- Memory delta and one runtime/simulation behavior result are recorded.
- Connected devices have a dependency update and secret-handling plan.
Shared output contract
Use the shared Arduino skill contract: state assumptions, required tools and versions, implementation steps, tests/evidence by proof stage, known limitations, and recovery/security notes.