一键导入
embedded-driver-design
Use when hardware configuration confirmed - creates detailed implementation plan with bite-sized tasks, exact file paths, complete code steps
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when hardware configuration confirmed - creates detailed implementation plan with bite-sized tasks, exact file paths, complete code steps
用 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 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)
Use after implementation complete - runs build-flash-monitor loop, verifies runtime behavior, no completion claims without fresh evidence
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-driver-design |
| description | Use when hardware configuration confirmed - creates detailed implementation plan with bite-sized tasks, exact file paths, complete code steps |
Create implementation plan assuming engineer has zero context and questionable taste. Document everything needed: files, code, testing, verification steps.
Context: Run after embedded-brainstorming approval.
Save plans to: docs/embedded/plans/YYYY-MM-DD-<driver>-plan.md
read docs/embedded/specs/YYYY-MM-DD-<feature>-spec.md
Based on task type:
| Task Type | Reference File |
|---|---|
| Driver dev | references/chips.md + hardware-interfaces.md |
| Protocol | references/protocols.md |
| GUI | references/gui-feedback.md |
| Debugging | references/debugging.md |
Map files BEFORE defining tasks:
| File | Responsibility |
|---|---|
include/driver.h | API declarations, constants |
src/driver.c | Implementation |
src/driver_test.c | Unit tests (if applicable) |
Each step = ONE action (2-5 minutes):
### Task 1: Driver Header
**Files:**
- Create: `include/lcd_st7789.h`
- [ ] **Step 1: Write header file**
```c
#ifndef LCD_ST7789_H
#define LCD_ST7789_H
// ... complete code
#endif
Run: idf.py build
Expected: No errors in header
git add include/lcd_st7789.h
git commit -m "feat: add ST7789 header"
Files:
Create: src/lcd_st7789.c
Modify: include/lcd_st7789.h (if needed)
Step 1: Write init function
esp_err_t lcd_st7789_init(void) {
// ... complete implementation
}
esp_err_t lcd_st7789_write(const uint8_t *data, size_t len) {
// Chunking for > 4092 bytes
}
Run: idf.py build
Expected: Exit 0
### 5. Plan Document Header
Every plan MUST start with:
```markdown
# [Driver Name] Implementation Plan
> **For agentic workers:** REQUIRED: Use embedded-implementation skill to execute this plan task-by-task.
**Goal:** [One sentence]
**Architecture:** [2-3 sentences]
**Constraints:**
- DMA <= 4092 bytes
- [Other hardware limits]
---
After writing complete plan:
| Check | Action |
|---|---|
| Spec coverage | Every requirement has task |
| Placeholder scan | No "TBD", "TODO", "implement later" |
| Type consistency | Function names match across tasks |
write docs/embedded/plans/YYYY-MM-DD-<driver>-plan.md
Offer execution choice:
Plan saved to docs/embedded/plans/<plan>.md
Two execution options:
1. Subagent-Driven - Fresh subagent per task, two-stage review
2. Inline Execution - Execute in current session
Which approach?
REQUIRED: Invoke embedded-implementation next.
These are plan failures - never write them:
### Task N: [Component Name]
**Files:**
- Create: `exact/path/to/file.c`
- Modify: `exact/path/to/file.c:123-145`
- [ ] **Step 1: [Action]**
[Complete code block]
- [ ] **Step 2: [Verification]**
Run: `[command]`
Expected: `[output]`
- [ ] **Step 3: Commit`
```bash
git add [files]
git commit -m "[message]"
## Red Flags - STOP
- Writing code during design phase
- "TBD" in any task
- Tasks without complete code
- Skipping file structure definition
- User hasn't approved brainstorming spec
## Output
Plan: docs/embedded/plans/YYYY-MM-DD--plan.md Tasks: N tasks defined Status: READY FOR IMPLEMENTATION Next: embedded-implementation