一键导入
embedded-verification
Use after implementation complete - runs build-flash-monitor loop, verifies runtime behavior, no completion claims without fresh evidence
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use after implementation complete - runs build-flash-monitor loop, verifies runtime behavior, no completion claims without fresh evidence
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when developing firmware on ESP32/STM32/RP2040/nRF52, experiencing DMA overflow, SPI timeout, LCD blank display, frame corruption, GPIO conflicts, sensor reading errors, Wi-Fi disconnect, or needing driver configuration, hardware debugging, display/GUI setup, protocol implementation, serial monitoring. Use even if user doesn't mention 'embedded' but asks about hardware, sensors, displays, microcontrollers, IoT, or device programming.
Use before any embedded development - explores hardware requirements, confirms configuration, validates feasibility, saves design spec
Use when hardware configuration confirmed - creates detailed implementation plan with bite-sized tasks, exact file paths, complete code steps
Use for LCD/GUI projects after verification passes - captures display via camera, analyzes layout/font/color, detects display issues
Use when implementation plan is ready - executes plan task-by-task with two-stage review (hardware spec then MISRA C)
Guide for embedded systems development on ESP32, STM32, RP2040, nRF52 chips. Use this skill whenever the user mentions embedded systems, firmware development, MCU programming, hardware drivers, sensors, LCD displays, IMU devices, SPI/I2C/UART interfaces, compilation, debugging, remote monitoring, Wi-Fi/BLE/MQTT protocols, or needs help with driver code generation, GUI layout design, hardware configuration, or device programming. Make sure to use this skill even if the user doesn't explicitly mention 'embedded' but asks about hardware, sensors, displays, device drivers, microcontrollers, or IoT applications.
| name | embedded-verification |
| description | Use after implementation complete - runs build-flash-monitor loop, verifies runtime behavior, no completion claims without fresh evidence |
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.
NO COMPLETION CLAIMS WITHOUT BUILD-FLASH-MONITOR VERIFICATION
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
| 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 |
# 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 }
# Build
idf.py build && echo "Build PASS"
# Flash + Monitor
idf.py -p /dev/ttyUSB0 flash monitor
Run: idf.py build
Check:
- Exit code = 0
- No errors in output
- No unexpected warnings
If FAIL:
- Analyze error
- Fix
- Re-build
Run: idf.py -p [PORT] flash
Check:
- Flash successful message
- No timeout errors
If FAIL:
- Check port (COMx / /dev/ttyUSBx)
- Check connection
- Re-flash
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
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 |
memory:
- "[Driver] verified: build-flash-monitor complete"
- "Hardware config: [specifics]"
| Claim | Required Evidence | Not Sufficient |
|---|---|---|
| "Driver complete" | Full loop pass | Build only |
| "Display works" | Monitor + visual | Monitor only |
| "Sensor reading" | Correct data in log | No output |
| "Wi-Fi connected" | Connection log | Code looks right |
ALL mean: STOP. Run verification commands.
## Verification Report
### Build
Command: idf.py build
Status: PASS / FAIL
Exit Code: 0 / [code]
Errors: [list or "None"]
### Flash
Command: idf.py -p COM3 flash
Status: PASS / FAIL
Port: COM3 / [actual port]
### Monitor
Duration: 30 seconds
Status: PASS / FAIL
Crashes: None / [error type]
Output: [key logs]
### Runtime
Feature: [name]
Status: PASS / FAIL
Evidence: [specific output]
### Summary
Verification: COMPLETE / INCOMPLETE
Ready for GUI Feedback: YES / NO
### Issues
[list or "None"]
If ALL verification PASS:
Verification complete. Invoking embedded-gui-feedback for display check.
If ANY verification FAIL:
Verification failed. Analyze issues, fix, re-verify.
Do NOT proceed to GUI feedback until full loop passes.
REQUIRED: Only invoke embedded-gui-feedback after ALL verification passes.
| Bad | Good |
|---|---|
| "Build passed" (no flash) | Full loop: build → flash → monitor |
| "Earlier session verified" | Fresh verification now |
| Truncated output reading | Full output check |
| Skip monitor phase | 30+ seconds monitoring |
| Claim without evidence | Evidence THEN claim |