wedsamuel1230/arduino-skills/library-selection

Library 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

1. Find the upstream source, release/tag, license, supported architectures, and

framework instructions. Prefer primary repositories and current release notes.

1. Compare candidate API fit, board variants, transitive dependencies, flash/

SRAM/heap impact, blocking behavior, concurrency, bus/pull-up assumptions, and error/recovery behavior.

1. Check open issues and maintenance signals without treating stars or install

count as compatibility proof.

1. Select a pinned version, record provenance and rationale, and document

unsupported board/framework branches.

1. Run a minimal compile fixture, then a simulated or target behavior check.

Anti-rationalization

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.