Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add lhbsaa/embedded-dev-skill --skill embedded-verificationgit clone --depth 1 https://github.com/lhbsaa/embedded-dev-skillWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/lhbsaa/embedded-dev-skill/embedded-verification)<a href="https://agentmods.dev/skills/lhbsaa/embedded-dev-skill/embedded-verification"><img src="https://agentmods.dev/badge/skills/lhbsaa/embedded-dev-skill/embedded-verification/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/lhbsaa/embedded-dev-skill/embedded-verification"><img src="https://agentmods.dev/badge/skills/lhbsaa/embedded-dev-skill/embedded-verification.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00026 | $0.01085 |
| Opus 5.5 | $0.00010 | $0.00434 |
| Sonnet 5.5 | $0.00005 | $0.00217 |
| Haiku 4.5 | $0.00003 | $0.00109 |
Grade A, and why
embedded-verification scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 211 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Embedded Verification
Overview
The Iron Law enforcement phase. No completion claims without fresh verification evidence.
Core principle: Evidence before claims, always.
Context: Run after embedded-implementation completes all tasks.
The Iron Law
NO COMPLETION CLAIMS WITHOUT BUILD-FLASH-MONITOR VERIFICATION
Verification Gate
BEFORE claiming ANY status:
1. IDENTIFY: What command proves this claim?
2. RUN: Execute FULL command (fresh, complete)
3. READ: Full output, check exit code, errors
4. VERIFY: Does output confirm?
5. ONLY THEN: Make the claim
Verification Types
| Type | Command | Expected |
|---|---|---|
| Build | idf.py build |
Exit 0, no errors |
| Flash | idf.py -p COM3 flash |
Exit 0, flash success |
| Monitor | idf.py monitor |
No crash, correct output |
| Full Loop | idf.py build flash monitor |
All pass |
Platform Commands
Windows PowerShell
# Build
idf.py build
if($LASTEXITCODE -eq 0) { echo "Build PASS" } else { echo "Build FAIL" }
# Flash + Monitor
idf.py -p COM3 flash; if($?) { idf.py monitor }
Linux/macOS Bash
# Build
idf.py build && echo "Build PASS"
# Flash + Monitor
idf.py -p /dev/ttyUSB0 flash monitor
Process
1. Build Verification
Run: idf.py build
Check:
- Exit code = 0
- No errors in output
- No unexpected warnings
If FAIL:
- Analyze error
- Fix
- Re-build
2. Flash Verification
Run: idf.py -p [PORT] flash
Check:
- Flash successful message
- No timeout errors
If FAIL:
- Check port (COMx / /dev/ttyUSBx)
- Check connection
- Re-flash
3. Monitor Verification
Run: idf.py monitor
Duration: 30-60 seconds minimum
Check:
- No Guru Meditation Error
- No assertion failures
- Expected log output present
- Initialization sequence logged
Use: scripts/serial_monitor.py for structured output
4. Runtime Behavior Check
Based on design spec:
| Feature | Verification |
|---|---|
| Display driver | Monitor shows init success |
| Sensor | Correct readings in log |
| Wi-Fi | Connected to AP |
| Protocol | Data transmission logged |
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 211 lines · 26 tokens per session scan A 31b355d5de96
embedded-verification is a skill published in the GitHub repository lhbsaa/embedded-dev-skill (10 stars, last pushed 2mo ago), licensed MIT. It adds 26 tokens to every session and 1,085 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
ruview-configure
Configure RuView — ESP32 sdkconfig variants, NVS provisioning, WiFi channel / MAC filter overrides (ADR-060), edge intelligence modules (ADR-041), sensing-server flags, multi-node mesh, and Cognitum Seed integration. Use when adjusting how a deployed RuView system behaves without changing code.
ruview-applications
Run RuView sensing applications — presence/occupancy, breathing & heart rate, activity & fall detection, 17-keypoint pose estimation (WiFlow), sleep monitoring & apnea screening, environment mapping, Mass Casualty Assessment (MAT), and the 3D point-cloud fusion demo. Use when someone wants to actually do something…
ruview-mmwave
Set up and run RuView mmWave / FMCW radar sensing — ESP32-C6 + Seeed MR60BHA2 (60 GHz, heart rate / breathing rate / presence) and HLK-LD2410 (24 GHz, presence + distance), plus mmWave↔WiFi-CSI sensor fusion (48-byte fused vitals, MR60BHA2/LD2410 auto-detect, v0.5.0+). Use when the deployment includes a…
ruview-verify
Verify a RuView build — full Rust workspace tests, the deterministic Python pipeline proof (SHA-256 Trust Kill Switch), firmware hash manifest, and the ADR-028 witness bundle with one-command self-verification. Use after any significant change, before merging a PR, or to produce an attestation bundle for a recipient.
provision-node
Build, flash, and provision an ESP32-S3/C6 CSI node for RuView — firmware variant choice, cross-platform checksum-verified esptool flashing, NVS/WiFi/channel/MAC-filter overrides, boot-log evidence.
train-pose
Train/evaluate WiFi pose models honestly — camera-supervised (MediaPipe + CSI) and camera-free (WiFlow), always checked against the mean-pose baseline before any PCK is quoted.