Conciseness

Mostly high-signal (tables, commands, flags, no teaching of concepts Claude already knows), but the semihosting exit-code mechanism ("main() returns the failure count; QEMU exits with that code; CI gates on it") is explained three times — in Overview, "ARM semihosting", and "Parsing results" — and the "not real-time" caveat is likewise repeated across "Timing the run", the Anti-patterns table, and Limitations. Quoted flag definitions ("-S 'freezes the CPU at startup'") also restate standard QEMU syntax; this repetition goes beyond the 'minor instances' of anchor 4 but is well short of anchor 2's padded explanatory prose.

Actionability

Fully executable, copy-paste-ready guidance throughout: the complete arm-none-eabi-gcc build line with --specs=rdimon.specs, the smoke-run invocation, the -d int,cpu_reset debug command, the two-terminal GDB session, QMP connection commands with concrete JSON-RPC examples, and the GitHub Actions pipeline in references/ci.md. The anti-patterns table pairs every failure mode with a specific fix (e.g., "Wrap in timeout 60 qemu-system-arm ..."), matching anchor 5.

Workflow Clarity

Sections follow the real pipeline order (When to use → Authoring → Building → Running → Parsing results → CI) and the exit code is explicitly established as the validation gate ("CI gates on the exit code directly"), with failure modes and recoveries enumerated in the Anti-patterns table. It falls short of anchor 5 because there is no numbered sequence or inline verify-before-proceeding checkpoint — error recovery lives in a separate table rather than feedback loops at the point of the step — but validation is clearly present, keeping it above anchor 3.

Progressive Disclosure

Verified against the actual bundle: SKILL.md is a genuine overview, and the three details that would bloat it — the full board/CPU mapping table, the invocation-flag table, and the complete CI pipeline — are split into references/boards.md, references/flags.md, and references/ci.md, all of which exist and contain exactly the promised content. References are one level deep (they cite external QEMU docs, not further skill files) and are clearly signaled at the point of need with inline markdown links, matching anchor 5.

Specificity

Lists several concrete capabilities — "qemu-system-arm, aarch64 and riscv32 machine and CPU flags, loading ELF binaries, semihosting exit codes" — but the tail of the list ("GDB and QMP, and CI") names tools without stating the actions performed with them, leaving minor gaps versus anchor 5's comprehensive action list. It is clearly above anchor 3, which allows only 1-2 concrete actions.

Completeness

Explicitly answers both: what (running embedded tests on a virtual MCU/SoC via QEMU machine/CPU flags, ELF loading, semihosting exit codes, GDB, QMP, CI) and when ("Use when embedded tests must run on a virtual MCU or SoC instead of the host or real hardware, for correct endianness, alignment and interrupts"). The when-clause is concrete and could not be more explicit, so it matches anchor 5 rather than 4.

Trigger Term Quality

Good natural-term coverage — "embedded tests", "virtual MCU or SoC", "endianness", "alignment", "ELF binaries", "semihosting", "GDB", "CI" are phrases an embedded developer would actually say. A few natural terms are missing: standalone "QEMU" (only embedded in the binary name), "emulation", and "Cortex-M"/"ARM" beyond aarch64, so it fits anchor 4 rather than 5's comprehensive synonym coverage.

Distinctiveness Conflict Risk

Clear niche — QEMU system emulation of virtual MCUs/SoCs for embedded tests — with named binaries (qemu-system-arm, aarch64, riscv32) as distinct triggers, and "instead of the host or real hardware" explicitly separates it from host-test and hardware-in-loop skills. Minimal conflict risk, matching anchor 5.