$npx -y skills add easyzoom/aix-skills --skill embedded-app-example-libsUse when studying, adapting, porting, or debugging embedded application example projects such as ESP32-IoT-Platform, HomeAutomation, CanBus-Triple, or TinyGameEngine
| 1 | # Embedded App Example Libs |
| 2 | |
| 3 | ## Overview |
| 4 | |
| 5 | Use this skill for application-level example projects and demo frameworks. Treat them as reference implementations to extract patterns from, not as drop-in libraries, unless the target platform and product requirements match closely. |
| 6 | |
| 7 | ## When To Use |
| 8 | |
| 9 | Use this skill when: |
| 10 | |
| 11 | - The user wants to adapt ESP32-IoT-Platform, HomeAutomation, CanBus-Triple, TinyGameEngine, or a similar example project. |
| 12 | - The task involves extracting architecture, drivers, protocols, UI/game loops, CAN logic, automation flows, or platform services from a demo. |
| 13 | - The user wants to port an example to a different board, RTOS, SDK, or product. |
| 14 | |
| 15 | Do not use this skill for small standalone libraries with clear APIs. Use the relevant integration skill instead. |
| 16 | |
| 17 | ## First Questions |
| 18 | |
| 19 | Ask for: |
| 20 | |
| 21 | - Example project name, source, and target board. |
| 22 | - What should be reused: architecture, driver, protocol, UI, game engine, automation flow, or build system. |
| 23 | - Current target platform and differences from the example. |
| 24 | - Dependencies: SDK, RTOS, network, display, storage, CAN, sensors, or cloud. |
| 25 | - Whether this is learning, prototype, or production work. |
| 26 | |
| 27 | ## Adaptation Checklist |
| 28 | |
| 29 | 1. Identify reusable layer. |
| 30 | Separate product idea, app logic, drivers, middleware, and build system. |
| 31 | |
| 32 | 1. Compare platform assumptions. |
| 33 | SDK version, pin mapping, memory, RTOS, filesystem, network, and peripherals must match or be adapted. |
| 34 | |
| 35 | 1. Avoid wholesale copy. |
| 36 | Extract the smallest pattern or module that solves the user's problem. |
| 37 | |
| 38 | 1. Replace secrets and endpoints. |
| 39 | Remove demo credentials, hardcoded cloud endpoints, keys, and private IDs. |
| 40 | |
| 41 | 1. Verify one scenario. |
| 42 | Run a minimal app flow on the target before adding features. |
| 43 | |
| 44 | ## Common Failures |
| 45 | |
| 46 | - Copying an entire demo and inheriting unused dependencies. |
| 47 | - Keeping board-specific pin maps or credentials. |
| 48 | - Treating example timing and memory as production-ready. |
| 49 | - Porting cloud or home automation flows without defining security and update policy. |
| 50 | - Adapting game/UI loops without measuring frame time and input latency. |
| 51 | |
| 52 | ## Verification |
| 53 | |
| 54 | Before claiming adaptation works: |
| 55 | |
| 56 | - State what was reused and what was intentionally not reused. |
| 57 | - Confirm target board, SDK, dependencies, and pin/config changes. |
| 58 | - Confirm one end-to-end scenario on target or simulator. |
| 59 | - Confirm secrets/private endpoints were not copied. |
| 60 | |
| 61 | ## Example |
| 62 | |
| 63 | User: |
| 64 | |
| 65 | ```text |
| 66 | 想参考一个 ESP32-IoT-Platform 做自己的家居控制。 |
| 67 | ``` |
| 68 | |
| 69 | Agent: |
| 70 | |
| 71 | 1. Asks which parts to reuse: Wi-Fi provisioning, MQTT, device model, UI, or storage. |
| 72 | 1. Separates reusable architecture from board-specific code. |
| 73 | 1. Checks secrets, OTA/update policy, and one minimal control flow before expanding. |