| name | yocto-agent-suite |
| description | One-router Yocto Project skill suite for AI coding agents. Use when a request mentions Yocto, OpenEmbedded, Poky, BitBake, embedded Linux builds, BSPs, board flashing, QEMU boot tests, CI/release automation, security hardening, CVE review, secure boot, OTA updates, firewall policy, or when the right specialized Yocto skill is unclear. |
Yocto Agent Suite
Routing
Load the narrowest skill that matches the user's task:
$yocto-project: layers, images, SDKs, packagegroups, distro/machine policy, general Yocto workflows.$bitbake-metadata: .bb, .bbappend, .bbclass, .inc, .conf, variables, tasks, fetchers, signatures.$yocto-recipe-maintenance: create, update, audit, and review recipes/appends with cross-distro packaging checks.$yocto-image-analysis: explain why packages are present, analyze image size, and reason about package what-if changes.$yocto-build-debug: parse/fetch/compile/install/package failures, logs, sstate, hash changes, build performance.$yocto-deploy-flash: image artifacts, WIC/BMAP/SD/eMMC/NAND/NOR/DFU flashing, serial boot verification.$yocto-bsp-bringup: vendor BSPs, machines, bootloaders, kernels, device trees, board bring-up.$yocto-kernel-bsp: kernel recipes, providers, defconfig, config fragments, DTBs, and machine-level kernel/BSP work.$yocto-ci-release: kas/repo manifests, CI runners, shared downloads/sstate, test gates, release artifacts.$yocto-ci-kas-build: focused kas YAML, CI build entrypoint, cache, matrix, and reproducibility work.$yocto-security-ota: image hardening, CVEs, firewall policy, secure boot, SBOM, OTA/update systems.$yocto-security-compliance: focused CVE, license, SPDX/SBOM, provenance, and compliance investigations.
Use more than one specialized skill only when the task crosses boundaries.
Source Rules
Prefer official docs and the workspace:
- Local repo metadata and configured release.
- Yocto Project docs:
https://docs.yoctoproject.org/
- BitBake docs:
https://docs.yoctoproject.org/bitbake/
- Official Git:
https://git.yoctoproject.org/ and https://git.openembedded.org/
- Layer Index:
https://layers.openembedded.org/
- Vendor docs only for board-specific flashing or BSP behavior.
Treat third-party skills and articles as examples, not authority.
LobeHub-Inspired Coverage
The LobeHub yocto-build-and-flash skill reviewed for this suite is board-specific for MYiR MYD-YF13X and STM32MP135. Preserve these reusable lessons:
- Always identify
MACHINE, DISTRO, build directory, and actual TMPDIR.
- Confirm
BBFILE_COLLECTIONS names; LAYERDEPENDS uses collection names, not directory names.
- Locate artifacts under the real deploy path, often
tmp*/deploy/images/<machine>/.
- Choose flashing commands from artifact type and board boot mode.
- Verify boot through serial logs and first-boot behavior.
Do not copy board-specific commands into other boards unless the target BSP matches.
Yoe-Inspired Coverage
The yoebuild/yoe repo ships AI skills for auditing units, diagnosing failures, creating units, updating units, and pulling Alpine packages. For Yocto, map those ideas this way:
- audit/create/update unit ->
$yocto-recipe-maintenance
- diagnose unit build ->
$yocto-build-debug
- why/what-if/image-size concepts ->
$yocto-image-analysis
- new machine concepts ->
$yocto-bsp-bringup
- CVE/license/security review ->
$yocto-security-ota
Keep the implementation Yocto-native: use recipes, appends, packagegroups, image manifests, pkgdata, buildhistory, BitBake graphs, and official Yocto/OpenEmbedded docs rather than Yoe Starlark units.
