embedded-framework

name	embedded-framework
description	Universal Embedded Knowledge Framework for Hermes Agent - recognizes embedded frameworks, maps domains, and applies native-first patterns
trigger	**/*.c, **/*.h, **/*.cpp, **/*.ino, **/*.py, **/*.md

Universal Embedded Knowledge Framework

Purpose

This skill enables Hermes to analyze, understand, and contribute to embedded projects by:

• Recognizing running domains
• Applying native framework patterns
• Respecting communication boundaries

When to Load

Load this skill when:

• Working on embedded projects (microcontrollers, RTOS, Linux embedded)
• Project contains: CMakeLists.txt, Kconfig, Makefile, FreeRTOS, NuttX, Zephyr, ESP-IDF, PX4, ROS/ROS2
• User asks about: embedded development, driver development, motor control, robotics, IoT, firmware

Core Rules (from ../../..)

When working on embedded projects, follow these rules:

1. Domain-First - Identify running domains before writing code
2. Native-First - Use framework's native APIs, not cross-framework abstractions
3. Clear Boundaries - Define communication protocols between domains

Environment Variables

EMBEDDED_SKILLPACK_DIR=/home/ubuntu/embedded-agent-skillpack

Framework Recognition

Indicator	Framework
uORB/, msg/, px4_add_module	PX4
apps/, frameworks/, Kconfig	openvela / NuttX
xTaskCreate, FreeRTOSConfig.h	FreeRTOS
rt_device, SConscript	RT-Thread
dts/, west.yml, Kconfig	Zephyr
sdkconfig, main/	ESP-IDF

Domain Recognition

Before writing any code, output a domain map:

## Running Domains Identified

1. **[Domain Name]**
   - Location: path/
   - Stack: technology
   - Responsibility: what it does

2. **[Another Domain]**
   - Location: path/
   - Stack: technology

Native-First Rules

Based on detected framework, load appropriate skill:

Framework	Load
PX4	domains/px4/README.md
Motor control	domains/motor_control/README.md
Robotics	domains/robotics/README.md
STM32	vendor_sdks/stm32cube.md
ESP32	vendor_sdks/esp_idf.md

Code Generation Checklist

Before outputting code, verify:

• Uses detected framework's native API
• Does NOT mix with other framework patterns
• Respects domain boundaries
• Follows existing code conventions
• Includes proper error handling

Example Commands

1. Analyze project structure:

   find . -name "*.c" -o -name "*.h" | head -20 && ls -la
   

2. Identify framework and domains:

   grep -r "xTaskCreate\|FreeRTOSConfig" . 2>/dev/null || \
   grep -r "uORB\|px4_add_module" . 2>/dev/null || \
   grep -r "rt_device\|rt_thread" . 2>/dev/null
   

3. Check for middleware/config files:

   ls *.cfg *.config Kconfig sdkconfig 2>/dev/null; \
   find . -name "Kconfig" -o -name "CMakeLists.txt" | head -10
   

Communication Boundaries

Cross-domain communication MUST use explicit protocols:

Transport	Protocol Format
UART	[HEADER, LEN, CMD, DATA, CRC]
CAN	[ID, DLC, DATA, CRC]
Ethernet	TCP/UDP with length prefix or protobuf

Critical Constraints

1. Never mix domain APIs - Linux uses POSIX, FreeRTOS uses task/queue
2. Never bypass framework conventions - PX4 uses uORB, Zephyr uses device tree
3. Never put business logic in drivers - Drivers handle hardware only
4. Never block in ISR - ISRs are short and fast
5. Always define communication protocols - Between domains, use explicit framing

Activation Context

Load this skill when:

• Working on MCU/embedded projects (*.c, *.h, *.cpp, *.ino)
• Analyzing project structure for framework identification
• Writing embedded firmware or drivers
• Debugging embedded systems issues