CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

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

The canonical home for this skill is testland/googletest-embedded-arm

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 highly actionable, well-structured skill whose embedded-ARM specifics (cross-compile flags, semihosting, target limitations) are genuinely non-obvious and the bundle split is clean. The main weakness is token efficiency: primer-level GoogleTest authoring and assertion basics that Claude already knows occupy roughly a third of the body.

Suggestions

Compress the "Minimal test", "Fixtures", and "Fatal vs non-fatal" sections to the code/tables alone and drop the Primer quotes restating what TEST/TEST_F arguments mean — Claude already knows GoogleTest basics, so the body only needs the embedded-specific deltas.

Move the generic "Command-line flags" table (gtest_filter/gtest_output/gtest_shuffle/gtest_repeat are standard GoogleTest) into references/cross-compile-and-ci.md alongside the full flag set it already points to, keeping only the embedded-relevant flags inline.

Add an explicit error-recovery loop to the worked example (e.g., if the QEMU exit code is nonzero or the XML gate counts failing testcases, re-run with --gtest_filter to isolate the failure before editing the test), which would raise workflow clarity from checkpoint-present to feedback-loop-complete.

DimensionReasoningScore

Conciseness

The embedded-specific guidance earns its tokens (mandatory "-DGTEST_HAS_PTHREAD=0", "--specs=rdimon.specs", death-test and Cortex-M0 heap limitations), but the "Minimal test", "Fixtures", "Fatal vs non-fatal", and generic flag-table sections recap standard GoogleTest knowledge Claude already has, including Primer quotes restating what TEST arguments mean. Mostly efficient with some unnecessary explanation fits the 3 anchor; it is not a 2 because there is no padded prose and the content is dense tables and code, but not a 4 because several sections explain known concepts.

3 / 5

Actionability

The body provides copy-paste-ready material for the common path: a compilable minimal test, a fixture, the host cmake build/run, the full arm-none-eabi-g++ command with every required flag, the QEMU invocation with exit-code propagation, and an anti-patterns table pairing each failure with its fix. This matches the fully-executable anchor; the only deferral (fetching GoogleTest and the CMakeLists config) is explicitly signaled to the reference file.

5 / 5

Workflow Clarity

"How to use" gives a 5-step sequence and the worked example is numbered end-to-end with expected output shown ("[ PASSED ] 2 tests.", "echo $?") and explicit CI gates (host on JUnit XML, QEMU on semihosting exit code). Checkpoints are present, so this is above the 3 anchor, but there is no explicit validate-then-fix-then-retry error-recovery loop, keeping it below the 5 anchor.

4 / 5

Progressive Disclosure

The overview keeps only the core path inline and moves advanced material (TEST_P, TYPED_TEST, death tests, the full flag set, XML/JSON schema, CI integration) into two clearly linked, one-level-deep reference files that both exist and contain that content. Navigation is well signaled with inline links plus a References section, matching the 5 anchor.

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: it states both what the skill does and when to use it in concrete, natural terms, and explicitly disambiguates the closest alternative skill. The only gap is missing common synonyms like "gtest"/"gmock" that users frequently type.

DimensionReasoningScore

Specificity

The description enumerates concrete actions across the whole workflow — "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" — covering authoring, assertion semantics, mocking, building, running, and CI reporting. This matches the comprehensive-coverage anchor rather than the 'several actions with minor gaps' anchor.

5 / 5

Completeness

It opens with an explicit trigger clause — "Use when embedded C++ (C++17 or later) on ARM needs unit tests with GoogleTest" — and follows with a concrete what-list, so both what and when are explicitly answered. The closing "Pure C uses unity-test-framework-c" further sharpens the when-not-to-use boundary, matching the 5 anchor rather than the 4 anchor's weaker when-clause.

5 / 5

Trigger Term Quality

It includes many natural phrases a user would say ("embedded C++", "ARM", "unit tests", "GoogleTest", "fixtures", "QEMU", "arm-none-eabi-g++", "XML output", "CI"), but common synonyms such as "gtest"/"gmock" (only the GoogleTest/GoogleMock spellings appear) are missing. Good coverage with a few natural terms absent fits the 4 anchor, below the synonym-and-extension completeness of a 5.

4 / 5

Distinctiveness Conflict Risk

The niche is narrow (embedded C++ on ARM with GoogleTest) and the description explicitly redirects the nearest competing case ("Pure C uses unity-test-framework-c"), so it is unlikely to trigger for the wrong skill. This is a clear niche with distinct triggers and minimal conflict 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

Repository

testland/qa

Path

plugins/qa-embedded/skills/googletest-embedded-arm/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.