Everything Yocman does, from a failed task to a flashed board
36 commands, one CLI. Each runs locally against your build directory or project. The AI layer is optional for analyses and never touches your files without your confirmation.
Diagnose and fix
- fix
- explain
- ask
- context
- login
- --dry-run
- --fresh
When bitbake fails, yocman fix reads the failing task log, works out the cause with read-only tools and proposes a unified diff against your own layer. You confirm, it applies the patch and re-runs the task. Every diagnosis is kept in your private history, so the same failure is answered from it next time, without new AI usage.
- explain gives the diagnosis without changing anything
- A change found by ask or explain is kept: yocman fix applies it later
- A failure already solved for you is answered at once; --fresh asks the AI again
- Patches go to your own layers, never to poky or upstream ones
- --dry-run prints the masked payload and sends nothing
Commands
- fix
- Fix a failed task: patch for your layer, applied after confirmation, task re-run; with no failure, apply the change ask or explain proposed
- explain
- Explain the last build failure without changing anything; a fix it finds is kept for yocman fix
- ask
- Ask a question about your project; a change it finds in a recipe is kept for yocman fix
- context
- Show the release, machine, distro and layers Yocman detected, offline
- login
- Store your API key and check it against the service
Analyse the build
- doctor
- rules
- conf
- layers check
- deps
- why
- provides
- unused
- orphans
- duplicates
- size
- buildtime
- sstate
- boot
- --no-ai
Deterministic analyses of your build directory, from the files bitbake already writes: configuration and layers, dependency chains, image contents and size, build time, shared-state reuse and boot time. Facts come from the files; an optional AI summary interprets them.
- why shows the chains that pull a package into the image
- size diff compares two builds or buildhistory revisions package by package
- sstate finds the recipes rebuilt at every build
- doctor tells you which data source is missing and how to enable it
Commands
- doctor
- List the data sources in the build directory and how to enable the missing ones
- rules
- List every analysis rule with its id, category and severity
- conf
- Check local.conf, bblayers.conf, auto.conf and site.conf
- layers check
- Check the layers of bblayers.conf: missing, listed twice, incompatible with the release, orphan .bbappend
- deps
- Dependency tree of a package, runtime or build time, and who depends on it
- why
- Why a package is in the image: the chains from IMAGE_INSTALL
- provides
- Which package installs a given file in the image
- unused
- Packages that are candidates for removal, to review
- orphans
- Recipes that are built but never reach the image
- duplicates
- Duplicate functionality in the image, such as two SSH servers
- size
- Image size by package, file and category; size diff compares two builds
- buildtime
- Longest tasks and recipes from buildstats, and the effective parallelism
- sstate
- Shared-state reuse, and the recipes rebuilt at every build
- boot
- Boot time of the target from systemd-analyze blame and critical-chain
Security and compliance
- audit
- cve
- secrets
- users
- perms
- services
- kernel-audit
- licenses
- sbom
- cra report
Audit the image you actually ship: unpatched CVEs, embedded secrets, accounts and permissions, enabled services, kernel hardening, licenses and the SPDX SBOM, with a score per category.
- Secrets are reported by location and type, never displayed
- cve diff shows what a release update fixed or introduced
- kernel-audit checks the kernel .config against a hardening list
- Markdown and JSON reports for reviews and audits
Commands
- audit
- Full security and compliance audit with a score per category
- cve
- Unpatched CVEs from the cve-check report by CVSS; cve diff compares two builds
- secrets
- Keys, tokens and passwords embedded in the rootfs and layers, never displayed
- users
- Accounts: empty passwords, extra UID 0, weak hashes, login shells
- perms
- File permissions: setuid, world-writable, sensitive files, unknown owners
- services
- Services enabled at boot, insecure network services, SSH and debug settings
- kernel-audit
- Kernel .config against a hardening checklist
- licenses
- GPLv3, proprietary and unclear licenses, and source obligations
- sbom
- SPDX SBOM presence and consistency with the image
- cra report
- Cyber Resilience Act readiness: build-side evidence from cve, secrets, sbom, licenses and kernel, mapped to CRA requirement areas
Start a project
- init
- add
- remove
- build
- shell
- env
- flash
- init --describe
- init --board-search
Create a kas project for one of 21 verified boards (Raspberry Pi, BeagleBone, Radxa, Orange Pi, i.MX 8M Plus EVK, QEMU…), or describe it in your own words and let the AI fill in the choices. Add features such as SSH, Wi-Fi, Qt 6 or Docker, build on the host or in the kas container with live progress, and flash an SD card with a device check you cannot skip.
- Board catalogue checked against the real layer repositories
- init --board-search looks up other boards in the OpenEmbedded layer index
- build shows the phase, the running tasks and the time left
- env switches between host and container after checking the prerequisites
- flash only lists removable disks and asks you to type the device name
Commands
- init
- Create a kas project for a verified board and release; --describe lets the AI fill in the choices
- add
- Add a feature (SSH, Wi-Fi, Qt 6, Docker…) with a diff to confirm and a commit
- remove
- Remove a feature, refused while another feature still needs it
- build
- Build the image with live progress: phase, running tasks, time left
- shell
- Open a shell with the bitbake environment, on the host or in the container
- env
- Check and switch the build environment between host and container, update the kas image
- flash
- Write the image to an SD card or USB drive, removable disks only, with a typed confirmation
Integrations
- --format json
- --fail-on
- --no-ai
- VS Code(coming soon)
Yocman is a plain CLI: it fits in any CI runner. Every analysis has machine-readable output and exit codes you can gate a pipeline on.
- --fail-on high exits with 1 when a finding reaches that level
- --no-ai keeps a pipeline fully offline
- A VS Code extension is coming soon
The free plan covers fixes, explanations and every local analysis.
Get started free