embedded-driver-design

Start from an approved design spec, load the relevant reference files for your task type, define the file structure first, then break work into bite-sized tasks. Each task needs complete code, a build verification command, and a git commit step.

A driver plan should include a goal statement, architecture summary, hardware constraints such as DMA buffer limits, exact file paths for headers and source files, and tasks with complete code blocks. It must avoid placeholders like TBD or TODO.

No, this skill only creates the implementation plan and enforces a hard gate against writing production code during the design phase. Code execution happens in the separate embedded-implementation phase that consumes the saved plan.

Plans fail when they contain placeholders, skip file structure definitions, omit verification steps, or have inconsistent function names across tasks. A self-review pass checking spec coverage and type consistency catches these issues before execution.

Run it after the brainstorming spec has been approved and hardware configuration is confirmed. Running it without an approved spec is flagged as a red flag, since the plan depends on confirmed requirements.