CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

testland/googletest-embedded-arm

Use when embedded C++ (C++17 or later) on ARM needs unit tests with GoogleTest: TEST, TEST_F and parameterized tests, EXPECT vs ASSERT, fixtures, GoogleMock, cross-compiling with arm-none-eabi-g++, running on host or QEMU and XML output for CI. Pure C uses unity-test-framework-c.

Quality

87%

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

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, highly actionable skill body with excellent progressive disclosure into two real one-level-deep reference files and an executable end-to-end worked example. The main cost is token budget: several passages re-explain standard GoogleTest concepts and quote the Primer verbatim where the embedded-specific guidance alone would carry the skill, and the workflow lacks an explicit error-recovery loop.

Suggestions

Trim the basic-GoogleTest explanations Claude already knows — the sentence explaining what TEST() registers, the EXPECT-vs-ASSERT guidance already carried by the table, the fixture-freshness Primer quote, and the "Google's C++ test framework" identity sentence in the Overview — keeping only the embedded-specific deviations from standard usage.

Drop or relocate version-sensitive statements ("The 1.17.x branch 'requires at least C++17'") out of the prose, since version pinning dates the skill and adds tokens without changing what Claude should do.

Add an explicit validate-and-retry step to the Worked example (e.g., 'if the XML gate counts failing testcases or the QEMU exit code is nonzero, re-run with --gtest_filter to isolate the failing test, fix, and re-gate') so the workflow's error-recovery path is in the sequence itself rather than only implied by the Anti-patterns table.

DimensionReasoningScore

Conciseness

The embedded-specific content (semihosting stubs, "--specs=rdimon.specs", "-DGTEST_HAS_PTHREAD=0", heap headroom limits, shuffle-seed determinism) is genuinely non-obvious and token-efficient, but the body repeatedly explains GoogleTest basics Claude already knows — what TEST() registers, EXPECT-vs-ASSERT semantics, fixture freshness, "Google's C++ test framework" identity — and pads with verbatim Primer quotes and a version-pinned statement ("The 1.17.x branch 'requires at least C++17'"). This is "mostly efficient but includes some unnecessary explanation", matching anchor 3 rather than anchor 4's minor trimmable instances.

3 / 5

Actionability

Everything needed to execute is concrete and copy-paste ready: a complete minimal test and fixture in C++, host build/run commands with expected output, the full arm-none-eabi-g++ cross-compile line, the QEMU invocation with semihosting config, "--gtest_output=xml:results.xml" gating, and a flag table. The common cases (author, build host, cross-compile, run under QEMU, gate CI) are each covered by runnable commands, matching anchor 5.

5 / 5

Workflow Clarity

"How to use" gives a clear 5-step sequence and the Worked example runs author-to-QEMU with explicit checkpoints (expected "[ PASSED ] 2 tests" output, "echo $?" exit-code propagation, "gate the host job on the JUnit XML and the QEMU job on the semihosting exit code"), and the Anti-patterns table maps failure modes to fixes. It stops short of anchor 5 because the sequence itself contains no explicit validate→fix→retry feedback loop; error recovery lives in a separate table rather than in the workflow steps.

4 / 5

Progressive Disclosure

The body is a genuine overview: core authoring, the fatal-vs-non-fatal table, common flags, and one end-to-end worked example stay inline, while advanced variants (TEST_P/TYPED_TEST/death tests) and the full toolchain/XML schema/CI pattern are split into two real, verified reference files (references/authoring-variants.md, references/cross-compile-and-ci.md) that are one level deep and clearly signaled with descriptive inline links plus a closing References section. This matches anchor 5's clear overview with well-signaled one-level-deep references.

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: explicit "Use when" trigger, comprehensive concrete capability list, third-person imperative form, and an explicit boundary against the pure-C sibling skill. The only weakness is that the ubiquitous "gtest" synonym is confined to metadata keywords rather than the description text.

DimensionReasoningScore

Specificity

The description lists multiple concrete capabilities — "TEST, TEST_F and parameterized tests, EXPECT vs ASSERT, fixtures, GoogleMock, cross-compiling with arm-none-eabi-g++, running on host or QEMU and XML output for CI" — giving comprehensive, specific coverage of what the skill does. It exceeds anchor 4 because no meaningful capability area is left out and every item is a concrete action or feature, not generic filler.

5 / 5

Completeness

It explicitly answers both questions: the what is the enumerated GoogleTest capability list, and the when is the concrete trigger phrase "Use when embedded C++ (C++17 or later) on ARM needs unit tests with GoogleTest", plus a boundary statement "Pure C uses unity-test-framework-c". This matches the anchor-5 example pattern of a clear what followed by explicit when-conditions.

5 / 5

Trigger Term Quality

Natural keywords are dense and would be spoken by users needing this skill ("unit tests", "GoogleTest", "QEMU", "cross-compiling", "CI", "embedded C++", "ARM", "arm-none-eabi-g++"), matching anchor 4's "good keyword coverage; a few natural terms missing". It falls short of anchor 5 because the very common synonym "gtest" (users say "set up gtest for my STM32 project") appears only in metadata keywords, not in the description itself.

4 / 5

Distinctiveness Conflict Risk

The niche is distinct — embedded ARM C++ with GoogleTest — and the description actively disambiguates the nearest conflicting skill with "Pure C uses unity-test-framework-c". Overlap risk with sibling test-framework skills is resolved in the text itself, so it sits at anchor 5 rather than 4's "minor overlap risk".

5 / 5

Total

19

/

20

Passed

Validation

93%

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

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

referenced_paths_exist

Referenced path issues: 3 missing

Warning

Total

15

/

16

Passed

Reviewed

On this page