Embedded Framework Libs
Overview
Use this skill for framework-style embedded libraries that shape project architecture rather than one feature. Cover PLOOC, Avem, PowerManagement, and similar libraries by focusing on ownership, lifecycle, configuration, coupling, and migration risk.
When To Use
Use this skill when:
- The user wants to add or evaluate PLOOC, Avem, PowerManagement, or a similar embedded framework.
- The task involves object-oriented C patterns, module architecture, power-management framework integration, lifecycle hooks, or broad project restructuring.
- The user is unsure whether a framework is appropriate for a small MCU project.
Do not use this skill for small single-purpose utility libraries that can be integrated locally without architecture impact.
First Questions
Ask for:
- Library/framework name and source.
- Existing project architecture and target MCU/RTOS.
- Problem the framework is meant to solve.
- Code size, RAM, timing, safety, and team familiarity constraints.
- Whether this is greenfield, migration, or partial adoption.
Integration Checklist
Validate need.
Confirm the framework solves a real recurring problem and is not added for style alone.
Define boundary.
Decide which modules use the framework and which remain plain C.
Check lifecycle.
Init, start, stop, suspend, resume, and deinit order must be explicit.
Keep platform hooks isolated.
Hardware, RTOS, allocator, timebase, and logging hooks should not leak across application modules.
Migrate incrementally.
Wrap one small module first and verify behavior before broad adoption.
Common Failures
- Applying an OOP-in-C framework to every file and increasing complexity.
- Hidden dynamic allocation in a no-heap project.
- Power-management hooks conflict with drivers or RTOS idle.
- Initialization order becomes implicit and fragile.
- Framework abstractions hide timing-critical hardware operations.
Verification
Before claiming framework integration works:
- State the specific problem solved and the modules in scope.
- Confirm init/lifecycle order and platform hooks.
- Confirm code size/RAM impact if relevant.
- Confirm one migrated module works and rollback is possible.
Example
User:
想在老项目里引入 PLOOC 整理模块。
Agent:
- Asks what module complexity PLOOC should solve and which modules are in scope.
- Recommends one pilot module instead of whole-project migration.
- Verifies code size, init order, and whether the abstraction improves testing/debugging.
1---2name: embedded-framework-libs3description: Use when integrating, evaluating, configuring, or debugging embedded C framework libraries such as PLOOC, Avem, or PowerManagement4---56# Embedded Framework Libs78## Overview910Use this skill for framework-style embedded libraries that shape project architecture rather than one feature. Cover PLOOC, Avem, PowerManagement, and similar libraries by focusing on ownership, lifecycle, configuration, coupling, and migration risk.1112## When To Use1314Use this skill when:1516- The user wants to add or evaluate PLOOC, Avem, PowerManagement, or a similar embedded framework.17- The task involves object-oriented C patterns, module architecture, power-management framework integration, lifecycle hooks, or broad project restructuring.18- The user is unsure whether a framework is appropriate for a small MCU project.1920Do not use this skill for small single-purpose utility libraries that can be integrated locally without architecture impact.2122## First Questions2324Ask for:2526- Library/framework name and source.27- Existing project architecture and target MCU/RTOS.28- Problem the framework is meant to solve.29- Code size, RAM, timing, safety, and team familiarity constraints.30- Whether this is greenfield, migration, or partial adoption.3132## Integration Checklist33341. Validate need.35 Confirm the framework solves a real recurring problem and is not added for style alone.36371. Define boundary.38 Decide which modules use the framework and which remain plain C.39401. Check lifecycle.41 Init, start, stop, suspend, resume, and deinit order must be explicit.42431. Keep platform hooks isolated.44 Hardware, RTOS, allocator, timebase, and logging hooks should not leak across application modules.45461. Migrate incrementally.47 Wrap one small module first and verify behavior before broad adoption.4849## Common Failures5051- Applying an OOP-in-C framework to every file and increasing complexity.52- Hidden dynamic allocation in a no-heap project.53- Power-management hooks conflict with drivers or RTOS idle.54- Initialization order becomes implicit and fragile.55- Framework abstractions hide timing-critical hardware operations.5657## Verification5859Before claiming framework integration works:6061- State the specific problem solved and the modules in scope.62- Confirm init/lifecycle order and platform hooks.63- Confirm code size/RAM impact if relevant.64- Confirm one migrated module works and rollback is possible.6566## Example6768User:6970```text71想在老项目里引入 PLOOC 整理模块。72```7374Agent:75761. Asks what module complexity PLOOC should solve and which modules are in scope.771. Recommends one pilot module instead of whole-project migration.781. Verifies code size, init order, and whether the abstraction improves testing/debugging.
easyzoom