CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

testland/qemu-system-test-runner

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: qemu-system-arm, aarch64 and riscv32 machine and CPU flags, loading ELF binaries, semihosting exit codes, GDB and QMP, and CI.

Quality

91%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

Quality

Content

86%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured, highly actionable skill body: every stage of the build-run-parse-CI pipeline has executable commands, and detail is correctly offloaded to three real one-level-deep reference files. The two weaker spots are mild citation/phrasing redundancy and the absence of an explicit error-recovery feedback loop in the workflow.

Suggestions

Trim the repeated 'Per the same invocation page / per the invocation page' citation framing to a single citation convention (e.g., one 'Flags per the QEMU invocation docs' note), tightening conciseness.

Add an explicit feedback loop after the smoke run, e.g., 'If QEMU produces no output and never exits, verify -semihosting-config enable=on,target=native and the rdimon link, then re-run' — converting the anti-patterns table's knowledge into a validate-fix-retry step.

Add a short 'Verify' checkpoint in the CI section (e.g., confirm $? equals the Unity failure count before gating) to make the exit-code validation step explicit rather than implied.

DimensionReasoningScore

Conciseness

The body is dense and command-first, assuming Claude's competence (no basic explanations of QEMU, ELF, or GDB), with bulk detail correctly deferred to references/. Minor trimmable content remains — repeated 'Per the same invocation page' citation phrasing and the Overview's pipeline rationale — so it sits at 'efficient; minor instances of over-explanation', not the fully lean 5 anchor.

4 / 5

Actionability

Fully executable, copy-paste-ready commands throughout: the arm-none-eabi-gcc build with --specs=rdimon.specs, the smoke-run invocation, the -d int,cpu_reset,unimp debug run, two-terminal GDB session, QMP example with concrete JSON-RPC commands, and a CI pipeline in references/ci.md. Expected output and exit-code semantics are shown for the common Cortex-M4 case, matching the top anchor.

5 / 5

Workflow Clarity

The Authoring → Building → Running → Parsing results → CI section ordering gives a clear sequence, and checkpoints exist (expected smoke output, exit-code gating for CI, timeout wrapping in the anti-patterns table). It falls short of the 5 anchor because there is no explicit validate-and-retry feedback loop (e.g., 'if QEMU never exits, verify semihosting flags and re-run'), but checkpoints are present enough to exceed the 3 anchor.

4 / 5

Progressive Disclosure

Clear overview with well-signaled, one-level-deep references — [references/boards.md], [references/flags.md], and [references/ci.md] are all real files (verified) containing the full flag table, machine list, and CI pipeline respectively, with no further nesting. Content is appropriately split: the spine keeps only the common Cortex-M3/M4 mapping and smoke run, matching the top anchor.

5 / 5

Total

18

/

20

Passed

Description

92%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description with an explicit, well-scoped 'Use when' trigger and a comprehensive, concrete capability list in third-person imperative style. The only weakness is trigger-term coverage: it lacks a few natural synonyms (e.g., 'emulate', bare 'qemu', 'cortex-m') that users would commonly say.

DimensionReasoningScore

Specificity

Lists multiple concrete capabilities — 'qemu-system-arm, aarch64 and riscv32 machine and CPU flags', 'loading ELF binaries', 'semihosting exit codes, GDB and QMP, and CI' — covering the full run-diagnose-gate pipeline comprehensively. Fits the 'multiple specific concrete actions; comprehensive coverage' anchor, not 4, since the action list has no notable coverage gaps for the domain.

5 / 5

Completeness

Explicitly answers 'when' with a concrete trigger clause ('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') and 'what' with an enumerated capability list. Matches the top anchor; not 4 because the when-clause is specific rather than merely present.

5 / 5

Trigger Term Quality

Good natural keywords ('embedded tests', 'virtual MCU', 'SoC', 'semihosting', 'GDB', 'CI') that users would plausibly say, but common synonyms and phrasings are missing — no 'emulate'/'emulation', bare 'qemu', 'cortex-m', or 'run tests under QEMU'. Fits 'good keyword coverage; a few natural terms missing', not 5, because the synonym/variation coverage is incomplete.

4 / 5

Distinctiveness Conflict Risk

The trigger 'virtual MCU or SoC instead of the host or real hardware' carves a clear niche between host-side unit testing and hardware-in-loop, and the qemu-system-* binary names are highly distinctive triggers. Minimal conflict risk; not 4 because sibling skills (build frameworks, HIL) are explicitly separated by the 'instead of the host or real hardware' framing.

5 / 5

Total

19

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

On this page