CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/googletest-embedded-arm

Author and run GoogleTest 1.17+ for embedded C++ on ARM targets - TEST() / TEST_F() / TEST_P() / TYPED_TEST(), EXPECT_* vs ASSERT_* assertions, fixtures with SetUp() / TearDown(), value-parameterised tests, GoogleMock when paired, cross-compile with arm-none-eabi-g++, run on host or under QEMU via the qemu-system-test-runner skill, --gtest_filter / --gtest_output=xml:results.xml / --gtest_shuffle / --gtest_repeat command-line flags, and XML / JSON output parsing for CI. Use when the unit-under-test is C++ (modern C++17+) and the team wants the de-facto C++ test framework instead of the C-only Unity. For C use unity-test-framework-c; for pure mocks use cmock-reference.

74

Quality

93%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

Overview
Quality
Evals
Security
Files

Quality

Content

85%

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

A high-quality, actionable skill body with executable code, full cross-compile/QEMU commands, a clear end-to-end workflow with gating checkpoints, and properly structured one-level-deep references. The only weakness is mild verbosity in the Overview and Primer quotes that restate concepts Claude already knows.

Suggestions

Trim the Overview's definition of GoogleTest ('Google's C++ test framework - an xUnit-style framework merged with GoogleMock') and the Primer quotes restating basic TEST() argument semantics; Claude already knows these and they add tokens without value.

Move the inline Primer citations (e.g. 'Per the Primer: ...') into the References section or drop them, keeping only the actionable rules such as 'prefer EXPECT_* unless the next line dereferences a possibly-null pointer'.

Consider folding the 'Command-line flags' table's full-set note into references/cross-compile-and-ci.md if it duplicates content already there, to keep the body lean.

DimensionReasoningScore

Conciseness

Mostly efficient (tables, commands, code earn their place), but the Overview explains what GoogleTest is ('Google's C++ test framework - an xUnit-style framework merged with GoogleMock') and Primer quotes restate basics like 'the name of the test suite, and the second argument is the test's name' that Claude already knows — matching the 'mostly efficient but includes some unnecessary explanation' anchor, not the lean score-3.

2 / 3

Actionability

Fully executable, copy-paste-ready guidance: complete TEST()/TEST_F() C++ examples, a full arm-none-eabi-g++ cross-compile line, and a qemu-system-arm invocation with required flags explained — the 'fully executable code/commands' anchor.

3 / 3

Workflow Clarity

Clear sequenced workflows — the 5-step 'How to use' and the end-to-end 'Worked example' (host build → cross-compile → QEMU run) — with explicit gating checkpoints ('gate the host job on the JUnit XML and the QEMU job on the semihosting exit code', 'echo $?').

3 / 3

Progressive Disclosure

SKILL.md is an overview with well-signaled, one-level-deep references — [references/authoring-variants.md] and [references/cross-compile-and-ci.md], both verified to exist — and content is appropriately split (variants, toolchain/CI details) rather than inlined.

3 / 3

Total

11

/

12

Passed

Description

100%

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 capabilities, natural trigger terms, an explicit 'Use when' clause, and clear disambiguation against sibling C/mock skills. Voice is consistently third person, so no specificity penalty applies.

DimensionReasoningScore

Specificity

Lists many concrete actions — 'TEST() / TEST_F() / TEST_P() / TYPED_TEST()', 'EXPECT_* vs ASSERT_*', 'fixtures with SetUp() / TearDown()', 'cross-compile with arm-none-eabi-g++', 'run on host or under QEMU', '--gtest_filter / --gtest_output=xml:results.xml' — matching the 'lists multiple specific concrete actions' anchor.

3 / 3

Completeness

Answers both what ('Author and run GoogleTest 1.17+ for embedded C++ on ARM targets...') and when ('Use when the unit-under-test is C++ (modern C++17+) and the team wants the de-facto C++ test framework'), with an explicit 'Use when' clause — the score-3 anchor.

3 / 3

Trigger Term Quality

Natural terms a user would say are well covered — 'GoogleTest', 'embedded C++', 'ARM', 'C++ test framework', 'GoogleMock', 'QEMU' — alongside metadata keywords (gtest, gmock, cortex-m, cortex-a); not merely jargon.

3 / 3

Distinctiveness Conflict Risk

Clear niche (embedded C++ on ARM with GoogleTest) and explicit routing away from siblings — 'For C use unity-test-framework-c; for pure mocks use cmock-reference' — making wrong-skill triggering unlikely.

3 / 3

Total

12

/

12

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.

Validation15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

Total

15

/

16

Passed

Reviewed

Table of Contents