hardware-tdd
Skill28 starsChanged 29 days agoMITView on GitHub
Use when planning tests for Arduino, ESP32, ESP32-S3, Pico, or Pico W firmware; deciding what can run off-target; using Wokwi or simulation; writing host fakes; or accepting a physical hardware feature without confusing compile proof with system proof.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- wedsamuel1230/arduino-skillsword for word, first seen Nov 1, 2026
Other versions1 project uses a version of this.
Word for word · 1
- wedsamuel1230/arduino-skills★ 28100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository48 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .cursor/rules/arduino-skills.mdcCursor rule
- cli-creatorSkill
- plugin-creatorSkill
- skill-creatorSkill
- arduino-cli-skillSkill
- arduino-code-generatorSkill
- arduino-project-builderSkill
- arduino-serial-monitorSkill
- arduino-workflow-routerSkill
- battery-selectorSkill
- board-selectionSkill
- board-supportSkill
- bom-generatorSkill
- boot-flash-recoverySkill
- bus-debuggingSkill
- circuit-debuggerSkill
- code-review-facilitatorSkill
- datasheet-interpreterSkill
- embedded-build-workflowSkill
- embedded-project-loopSkill
- enclosure-designerSkill
- error-message-explainerSkill
- fault-forensicsSkill
- field-power-and-connectivity-triagerSkill
- freertos-patternsSkill
- i2c-bringup-diagnosticianSkill
- library-selectionSkill
- memory-budgetingSkill
- memory-timing-debuggingSkill
- mermaid-diagram-generatorSkill
- micropython-developmentSkill
- non-blocking-patternsSkill
- ota-deployment-guardianSkill
- pico-sdk-developmentSkill
- pin-assignmentSkill
- power-budget-calculatorSkill
- probe-debuggingSkill
- readme-generatorSkill
- realtime-control-designSkill
- sensor-calibration-workbenchSkill
- sensor-signal-filteringSkill
- stm32-developmentSkill
- usb-debuggingSkill
- wireless-telemetrySkill
- wiring-safety-checkSkill
- zephyr-developmentSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 7 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 24
Write host tests for pure C/C++ logic using fakes for time, serial, sensors, and actuators.
- Distinctive: line 26
Use Wokwi or another simulator only for peripherals and timing that its model actually represents.
- Distinctive: line 28
Run an exact-board compile and static checks with the selected toolchain.
- Distinctive: line 29
Create a one-change target checklist: power-off continuity, controlled power-up, input observation, output inhibit, reset/recovery, and …
- Distinctive: line 31
Ask a physical gate for measurements, photos, or serial output.
- Distinctive: line 57
Every requirement maps to a test, proof stage, and artifact path.
- Distinctive: line 65
Use the shared Arduino skill contract: state assumptions, required tools and versions, implementation steps, tests/evidence by proof stage, …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Hardware TDD
Build the test ladder before claiming a feature is complete. Pure behavior can often be tested off-target; voltage, pin mux, timing under load, and physical assembly still require target evidence.
Intake
Record exact board/revision, framework/toolchain, hardware invariants, safety inhibits, simulator model, available instruments, test fixtures, and the proof stage required by the user.
Process
- Turn requirements into observable behavior and safety invariants.
- Write host tests for pure C/C++ logic using fakes for time, serial, sensors, and actuators. Keep hardware adapters thin.
- Use Wokwi or another simulator only for peripherals and timing that its model actually represents; record model limitations.
- Run an exact-board compile and static checks with the selected toolchain.
- Create a one-change target checklist: power-off continuity, controlled power-up, input observation, output inhibit, reset/recovery, and logs.
- Ask a physical gate for measurements, photos, or serial output. Do not infer target success from a host test or compile log.
- Record failures as evidence and keep the next test bounded.
Test matrix
| Layer | Example | Proves | Does not prove |
| Host | debounce/state/packet parser | deterministic logic | pin voltage or wiring |
| Simulation | modeled sensor/LED/UART | modeled interactions | regulator, clone, EMI, thermal behavior |
| Build | exact FQBN/environment | source and dependency compile | upload or behavior |
| Target | serial, meter, scope, photo | observed hardware behavior | field reliability unless loaded |
| System | integrated load/failure case | requirement under scenario | future deployment safety |
Anti-rationalization
| Shortcut | Response |
| "The unit test passed." | Keep all physical and system stages open. |
| "Wokwi matches the board." | List what the model omits and verify those items on hardware. |
| "The sketch compiled." | Require upload identity and target observations separately. |
| "The photo proves it works." | Require board identity, measurement context, and observed result. |
| "Mark it done and test later." | Keep the loop item blocked or needs-review until evidence exists. |
Verification
- Every requirement maps to a test, proof stage, and artifact path.
- Host/simulation/build/target/system results are labeled separately.
- Physical-only steps emit the concrete
Physical gateformat fromembedded-project-loop. - Failed and unverified cases remain visible in the report.
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.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.