CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/embedded-coverage-strategy-reference

Pure-reference catalog of code-coverage strategy for embedded C/C++: the criteria hierarchy (statement / branch / decision / condition / MC/DC), the gcov toolchain (.gcno/.gcda, --coverage), the LLVM source-based toolchain (llvm-profdata / llvm-cov), host-build vs QEMU-build instrumentation, MISRA-C:2012 and DO-178C structural-coverage expectations by safety level (DAL A maps to MC/DC), and report-format choices. Use when choosing what structural-coverage level to require and wiring gcov / llvm-cov into the build; physical .gcda retrieval from hardware is in hardware-in-loop-reference, QEMU machine flags in qemu-system-test-runner, and to author the embedded tests themselves use googletest-embedded-arm or unity-test-framework-c.

75

Quality

94%

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 strong reference-style body: executable commands for both gcov and LLVM toolchains, a genuine worked example, and a clean two-file bundle split with verified, well-signaled one-level-deep references. The main weaknesses are minor: a few verbatim documentation quotes and a repeated safety-level mapping that could be tightened, and the absence of explicit verification checkpoints inside the step sequences.

Suggestions

Trim the verbatim GCC/LCov documentation quotes (e.g. the multi-line quote about what --coverage does) down to the operative fact while keeping the citation link, removing the main over-explanation in the gcov section.

State the DAL/ASIL-to-criterion mapping once — keep the one-line summary in "How to use" and let references/safety-standards-and-formats.md carry the full mapping — instead of repeating it in "How to use", "Safety-standard coverage expectations", and the reference file.

Add explicit verification checkpoints to the step sequences, e.g. after running the test binary: 'verify parser.gcda exists next to parser.gcno before running gcov', mirroring the error-recovery guidance already in Anti-patterns.

DimensionReasoningScore

Conciseness

Overall lean — tables and code blocks carry the load, and it assumes Claude's competence (no basic-concept padding). However, there are minor trimmable spots: the multi-line verbatim GCC quote ("tells the compiler to generate additional information needed by gcov (basically a flow graph...)") restates what the flag table and link already establish, and the safety-level mapping (DAL A→MC/DC etc.) is stated three times across "How to use" step 1, "Safety-standard coverage expectations", and the reference file. This matches the score-4 anchor ('minor instances of over-explanation that could be trimmed'), not score 5's 'every token earns its place'.

4 / 5

Actionability

Fully executable, copy-paste-ready commands cover the common cases for both toolchains: the gcc build ("arm-none-eabi-gcc --coverage -O0 -g ..."), "gcov -b -c parser.c", "lcov --capture ... / genhtml", the clang build with "-fprofile-instr-generate -fcoverage-mapping", "llvm-profdata merge -sparse", and all three llvm-cov report forms, plus a complete end-to-end worked example. Matches the score-5 anchor: specific examples cover the common cases.

5 / 5

Workflow Clarity

The "How to use" section gives a clear numbered sequence (criterion → toolchain → instrument → where to run → artefact/gate) reinforced by a five-step worked example, and error-recovery guidance exists ("scan for ##### lines", "check gcov-tool overlap for saturated counts", the never-written-back .gcda anti-pattern with its _write/_exit fix). But the sequence itself lacks explicit verify-checkpoints (e.g. confirm the .gcda was written before running gcov), so it sits at score 4 ('most checkpoints present; minor validation gaps') rather than score 5's explicit validate-and-retry loops; it is clearly above score 3's merely-implicit checkpoints.

4 / 5

Progressive Disclosure

The body keeps overview-level content and pushes the full detail to two real, verified, one-level-deep reference files, each clearly signaled: "The full gcov flag table and the .gcov annotation sentinels ... are in references/gcov-flag-reference.md" and "The full per-standard table ... is in references/safety-standards-and-formats.md". Both files exist, contain exactly the promised tables, and do not nest further. Section headers and the "How to use" map make navigation easy — the score-5 anchor.

5 / 5

Total

18

/

20

Passed

Description

100%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.

An exemplary description: dense with specific tool, file, and standard tokens, an explicit 'Use when' trigger clause, and explicit routing that delimits the skill against four sibling skills. Third-person voice throughout with no padding; every clause carries a distinct token a matcher or user would use.

DimensionReasoningScore

Specificity

Enumerates multiple concrete topic areas with specific tokens: "the criteria hierarchy (statement / branch / decision / condition / MC/DC)", "the gcov toolchain (.gcno/.gcda, --coverage)", "the LLVM source-based toolchain (llvm-profdata / llvm-cov)", "MISRA-C:2012 and DO-178C structural-coverage expectations by safety level (DAL A maps to MC/DC)", plus instrumentation and report-format choices. Nothing vague remains; coverage of the declared scope is comprehensive, matching the score-5 anchor rather than the 'minor gaps' of score 4.

5 / 5

Completeness

Explicitly answers both what ("Pure-reference catalog of code-coverage strategy for embedded C/C++: ..." with an itemized scope) and when ("Use when choosing what structural-coverage level to require and wiring gcov / llvm-cov into the build") with concrete trigger phrases, matching the score-5 anchor exactly. The 'Use when' clause is present, so the completeness cap of 3 does not apply.

5 / 5

Trigger Term Quality

Contains the natural terms a user would say when needing this skill — "code-coverage", "coverage", "gcov", "llvm-cov", "MC/DC", "structural-coverage", "MISRA", "DO-178C", "embedded" — including synonyms and file extensions (.gcno/.gcda), matching the score-5 anchor's 'synonyms and file extensions' bar. No common variation (e.g. clang toolchain path, safety-level names) is missing.

5 / 5

Distinctiveness Conflict Risk

Occupies a clear niche (embedded structural-coverage strategy) and actively de-conflicts with sibling skills: "physical .gcda retrieval from hardware is in hardware-in-loop-reference, QEMU machine flags in qemu-system-test-runner, and to author the embedded tests themselves use googletest-embedded-arm or unity-test-framework-c". This explicit boundary routing gives minimal conflict risk, matching the score-5 anchor.

5 / 5

Total

20

/

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

Table of Contents