菜单
Use before any embedded development - explores hardware requirements, confirms configuration, validates feasibility, saves design spec
用 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 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)
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-brainstorming |
| description | Use before any embedded development - explores hardware requirements, confirms configuration, validates feasibility, saves design spec |
Turn hardware ideas into fully formed designs through systematic exploration.
Core principle: No code generation until hardware configuration confirmed and design approved.
Do NOT generate any driver code, write any implementation, or take any coding action until you have presented the design and the user has approved it. This applies to EVERY embedded project regardless of perceived simplicity.
1. Load Context → 2. Confirm Hardware → 3. Identify Constraints → 4. Propose Design → 5. Get Approval → 6. Next Skill
You MUST complete these items in order:
read AGENTS.md
Ask questions one at a time:
| Question | Why |
|---|---|
| Target chip? | Determines framework and constraints |
| Interface type? | SPI/I2C/UART config differs |
| Controller/model? | Datasheet lookup required |
| Resolution/config? | Display/sensor specific |
Prefer multiple choice when possible:
"Which chip family?"
A) ESP32-S3 (Wi-Fi, LCD, AI)
B) STM32F4 (Performance, DSP)
C) RP2040 (Low cost, PIO)
D) nRF52 (BLE, Low power)
Check hard limits:
| Chip | Key Constraint |
|---|---|
| ESP32-S3 | SPI DMA <= 4092 bytes |
| STM32 | Check DMA stream limits |
| RP2040 | PIO instruction limit |
| nRF52 | SoftDevice memory |
Present options with trade-offs:
Approach A: [Recommended]
- Pros: ...
- Cons: ...
- Why recommended: ...
Approach B: [Alternative]
- Pros: ...
- Cons: ...
Approach C: [Fallback]
- Pros: ...
- Cons: ...
Present design in sections (scaled to complexity):
## Hardware Configuration
- Chip: ESP32-S3
- Interface: SPI Mode 0, 40MHz
- Controller: ST7789
- Resolution: 240x240
## Architecture
- Three-layer: App → HAL → Driver
## Key Constraints
- DMA: 4092 byte chunks
- Frame buffer: Use PSRAM
## Implementation Plan
- Phase 1: Driver init
- Phase 2: Display functions
- Phase 3: GUI integration
Does this look correct?
Write validated design to:
docs/embedded/specs/YYYY-MM-DD-<feature>-spec.md
After user approval:
Design approved. Invoking embedded-driver-design skill to create implementation plan.
REQUIRED: Invoke embedded-driver-design skill next. Do NOT invoke any other skill.
| Bad Practice | Correct Approach |
|---|---|
| "Just generate the driver" | Brainstorm first, then implement |
| "This is simple, no design needed" | Every project needs design validation |
| Multiple questions in one message | Ask one at a time |
| Skip hardware confirmation | Verify chip/interface/controller |
ALL mean: STOP. Complete brainstorming process first.
After approval, report:
Design Spec: docs/embedded/specs/YYYY-MM-DD-<feature>-spec.md
Status: APPROVED
Next: embedded-driver-design