CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

embedded-coverage-strategy-reference

Use when deciding what code coverage level embedded C/C++ needs (statement, branch, MC/DC) and wiring gcov or llvm-cov into the build: host vs QEMU instrumentation, MISRA-C and DO-178C expectations by safety level, and report formats.

Quality

88%

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

The canonical home for this skill is testland/embedded-coverage-strategy-reference

SKILL.md
Quality
Evals
Security

Quality

Content

78%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 reference skill: executable commands throughout, a complete worked example, and exemplary progressive disclosure into two verified reference files. The main cost is token spend on concepts Claude already knows — the criteria-definition table, the LLVM region taxonomy, and a duplicated safety-level mapping — plus a missing error-recovery loop in the workflow.

Suggestions

Compress the coverage-criteria hierarchy table to the one non-obvious insight (escalation finds different defect classes: branch catches unreached else, MC/DC catches masked short-circuit conditions) and cite ISTQB term IDs, dropping the per-row definitions Claude already knows.

State the DAL/ASIL → criterion mapping once — in the safety-expectations section that points to references/safety-standards-and-formats.md — instead of repeating it in 'How to use' step 1 and again in the body section.

Add a validation checkpoint to the worked example (e.g. confirm coverage.info is non-empty and branch totals are present before gating the PR) with a one-line recovery hint for the common '.gcda missing' failure.

DimensionReasoningScore

Conciseness

Mostly efficient — command blocks, tables, and genuinely non-obvious details (-fcoverage-mcdc, --specs=rdimon.specs, __gcov_reset(), counter overflow) dominate — but the 6-row coverage-criteria definition table and the LLVM region taxonomy re-explain concepts Claude already knows, doc passages are quoted verbatim ('tells the compiler to generate additional information needed by gcov…'), and the DAL/ASIL mapping is stated in both 'How to use' step 1 and the 'Safety-standard coverage expectations' section. Not 4: these are several rather than minor instances of over-explanation; not 2: the majority of the body is concrete, non-generic guidance with no filler.

3 / 5

Actionability

Fully executable, copy-paste-ready commands for every toolchain path: 'arm-none-eabi-gcc --coverage -O0 -g …', 'gcov -b -c parser.c', 'lcov --capture … / genhtml …', 'clang --target=arm-none-eabi -fprofile-instr-generate -fcoverage-mapping …', 'llvm-profdata merge -sparse …', 'llvm-cov export … -format=lcov', plus a complete end-to-end worked example for the common case and an anti-patterns table with exact flags and spec files as fixes. Specific examples cover the common host-gcov case fully.

5 / 5

Workflow Clarity

'How to use' gives a clear 5-step numbered sequence (criterion → toolchain → instrument → where to run → artefact/gate) and the worked example repeats it concretely with per-step expected outputs ('writes parser.gcda', '-> parser.c.gcov (scan for ##### lines)') and named failure signals (gcov-tool overlap, missing .gcda). Not 5: no explicit validate→fix→retry loop (e.g. what to check when lcov capture finds no .gcda); not 3: checkpoints and expected artefacts are stated at each step rather than absent.

4 / 5

Progressive Disclosure

Clear overview with two well-signaled, one-level-deep references, each described before the link ('The full gcov flag table and the .gcov annotation sentinels … are in references/gcov-flag-reference.md'; 'The full per-standard table … is in references/safety-standards-and-formats.md'); both files exist and contain exactly the promised flag table, standards matrix, and producer/consumer format matrix, and the deep tables are correctly split out of the body. Navigation is easy with no nesting.

5 / 5

Total

17

/

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: concrete, third-person, with an explicit 'Use when' trigger clause and specific tools, criteria, and standards named. The only weakness is moderate synonym coverage — 'test coverage', 'lcov', 'clang', and coverage-gating phrasings are missing.

DimensionReasoningScore

Specificity

Enumerates multiple concrete capabilities — 'deciding what code coverage level embedded C/C++ needs (statement, branch, MC/DC)', 'wiring gcov or llvm-cov into the build', 'host vs QEMU instrumentation', 'MISRA-C and DO-178C expectations by safety level, and report formats' — giving comprehensive coverage of the skill's scope. Not 4: the actions are specific and complete within the niche rather than leaving minor gaps.

5 / 5

Completeness

Explicitly answers both 'when' ('Use when deciding what code coverage level embedded C/C++ needs … and wiring gcov or llvm-cov into the build') and 'what' (criterion selection, build wiring, instrumentation choice, standards expectations, report formats) in one sentence with concrete trigger phrases. Not 4: the 'when' is explicit and specific, not merely present.

5 / 5

Trigger Term Quality

Contains the natural terms users would say for this need: 'code coverage', 'gcov', 'llvm-cov', 'MC/DC', 'embedded C/C++', 'MISRA-C', 'DO-178C', 'QEMU'. Not 5: common synonyms and toolchain names a user might actually type are absent — 'test coverage', 'lcov', 'clang', 'coverage gate/threshold', '.gcda'.

4 / 5

Distinctiveness Conflict Risk

A clear niche — coverage strategy for embedded C/C++ under safety standards — with distinct tool and standard triggers (gcov, llvm-cov, MC/DC, MISRA-C, DO-178C) that sibling test-runner or build skills would not match. The 'host vs QEMU instrumentation' phrase touches QEMU-runner territory but is framed as a coverage instrumentation decision, keeping conflict risk minimal.

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.

Repository

testland/qa

Path

plugins/qa-embedded/skills/embedded-coverage-strategy-reference/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.