embedded-implementation

Executes embedded driver implementation plans task-by-task with hardware and MISRA C review stages.

Updated Sep 3, 2024
One-click install
npx skills add https://github.com/eminboydak/duckTerm --skill embedded-implementation-eminboydak
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: embedded-implementation
Source: https://github.com/eminboydak/duckTerm/tree/main/.agents/skills/embedded-dev/skills/embedded-implementation
Command: npx skills add https://github.com/eminboydak/duckTerm --skill embedded-implementation-eminboydak

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Embedded driver code often ships with hardware configuration errors (DMA overflows, wrong init sequences) and code quality violations (MISRA C) because reviews are skipped or inconsistent. This Skill enforces a disciplined task-by-task execution workflow where every generated driver passes a two-stage review before being committed. ## Core Features & Use Cases - Plan-Driven Execution: Loads a driver implementation plan from docs/embedded/plans and executes each task with a fresh subagent, tracking progress via a todo list. - Two-Stage Review Gate: Runs a hardware validator (DMA limits, interface config, init sequence) followed by a code quality reviewer (MISRA C, DRY, YAGNI) after every task, blocking progress until both approve. - Status Handling: Manages DONE, DONE_WITH_CONCERNS, NEEDS_DATASHEET, and BLOCKED statuses, then hands off to embedded-verification for the build-flash-monitor loop. - Use Case: After designing a UART driver plan for an STM32 target, run this Skill to generate the header and source files task by task, catching a DMA buffer over 4092 bytes in Stage 1 and a MISRA C violation in Stage 2 before any code is committed. ## Quick Start Execute the implementation plan at docs/embedded/plans for my driver, running the hardware and code quality reviews after each task.

Frequently Asked Questions about embedded-implementation

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I execute an embedded driver implementation plan with automated reviews?

Load the plan file from docs/embedded/plans, create a todo list of all tasks, then execute each task with a fresh subagent. After each task, run the hardware validator first, then the code quality reviewer, and only commit when both stages return APPROVED.

What does the two-stage review check in embedded driver code?

Stage 1 (hardware validator) checks DMA transfers stay within 4092 bytes, interface configuration, and initialization sequences. Stage 2 (code quality) checks MISRA C compliance, DRY, YAGNI, and general clean code practices.

When should I run embedded-implementation in the driver development workflow?

Run it after the embedded-driver-design phase has produced an implementation plan. It requires a plan file with tasks and context; once all tasks pass review, it hands off to embedded-verification for the build-flash-monitor loop.

What happens when a review stage fails during implementation?

The workflow stops and fixes the reported issues, then re-runs the same review stage. It does not proceed to the next stage or next task until the current review returns APPROVED, and fixes are applied one at a time.

What does the NEEDS_DATASHEET status mean during driver generation?

NEEDS_DATASHEET means the implementation subagent is missing the hardware initialization sequence required for the driver. You must provide the relevant datasheet information and re-dispatch the task before execution can continue.