Yocto project

Yocto Project

Core Workflow

1. Identify the target release before giving commands or editing metadata. Inspect branch names, conf/layer.conf, LAYERSERIES_COMPAT, bblayers.conf, README, kas*.yml, poky/meta/conf/distro/include/yocto-uninative.inc, or release tags.
2. Prefer the workspace's own metadata over generic examples. Search existing layers for the same pattern before inventing a new recipe, image feature, class, override, or machine setting.
3. Check official docs for version-sensitive behavior. Use yocto_doc_router.py with a topic name for a quick URL map, then open the relevant docs.
4. Make the smallest layer-local change that fits Yocto conventions. Avoid editing poky/ or upstream layers unless the user explicitly asks for an upstream patch.
5. Validate with BitBake-native tools whenever available: bitbake-layers, bitbake -e, bitbake -c listtasks, bitbake -c cleansstate, devtool, oe-pkgdata-util, or the existing project build wrapper.

Source Priority

Use official sources first:

• Local workspace metadata and build configuration.
• Yocto Project docs: https://docs.yoctoproject.org/
• BitBake manual: https://docs.yoctoproject.org/bitbake/
• Yocto source: https://git.yoctoproject.org/
• OpenEmbedded source: https://git.openembedded.org/
• OpenEmbedded Layer Index: https://layers.openembedded.org/

If the user asks for "latest", "current", "supported", "LTS", package versions, release notes, migration rules, or security status, verify online before answering.

Task Routing

• For recipe syntax, tasks, overrides, fetchers, signatures, or .bbappend mechanics, use $bitbake-metadata as the primary skill and return here for Yocto workflow context.
• For layers, images, SDKs, BSPs, distro/machine policy, build setup, package selection, or migration planning, stay in this skill.
• For kernel recipe and device-tree work, inspect existing machine and kernel metadata first, then read the kernel development sections from the official docs.

References

Read only the reference file needed for the task:

• official-sources.md: source list, docs version notes, release/branch selection rules.
• workflows.md: practical workflows for layers, images, SDKs, BSPs, packages, and troubleshooting.

Guardrails

• Do not assume a variable, class, package manager, init system, or override syntax is valid for every Yocto release.
• Do not use random blog snippets as authority when official docs or source metadata answer the question.
• Do not add broad config changes to local.conf when a layer, recipe, image, distro, or machine file is the durable location.
• Do not paper over build failures with INSANE_SKIP, BBMASK, COMPATIBLE_MACHINE, or task disabling unless the reason is documented and locally appropriate.
• Prefer .bbappend in the product layer over copying whole upstream recipes.