tdg-personal/cpp-testing
Use only when writing/updating/fixing C++ tests, configuring GoogleTest/CTest, diagnosing failing or flaky tests, or adding coverage/sanitizers.
74
74%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
72%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description excels at trigger term quality and distinctiveness, clearly carving out a niche around C++ testing with GoogleTest/CTest. However, it reads more as a 'when to use' directive than a complete skill description—it lacks an explicit 'what this skill does' statement describing the concrete capabilities or guidance it provides. The specificity of actions could also be improved with more concrete examples.
Suggestions
Add an explicit 'what' statement before the 'Use when' clause, e.g., 'Guides writing C++ unit tests with GoogleTest, configuring CTest in CMake, debugging flaky tests, and adding sanitizer/coverage instrumentation.'
Expand the action specificity with more concrete capabilities, such as 'create test fixtures, write EXPECT/ASSERT macros, configure CMakeLists.txt for CTest, interpret sanitizer output'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (C++ tests) and mentions several actions (writing, updating, fixing, configuring, diagnosing, adding coverage/sanitizers), but these are somewhat general verbs rather than deeply specific concrete actions like 'create test fixtures' or 'set up CMakeLists.txt for CTest'. | 2 / 3 |
Completeness | The description has a strong 'when' clause ('Use only when...') but the 'what does this do' part is essentially embedded within the when clause rather than explicitly stated. It tells Claude when to use it but doesn't clearly describe what the skill provides or teaches. | 2 / 3 |
Trigger Term Quality | Includes strong natural trigger terms users would say: 'C++ tests', 'GoogleTest', 'CTest', 'failing tests', 'flaky tests', 'coverage', 'sanitizers'. These cover common variations of how users would describe testing-related tasks. | 3 / 3 |
Distinctiveness Conflict Risk | Very clearly scoped to C++ testing with specific technologies (GoogleTest, CTest) and specific concerns (flaky tests, sanitizers, coverage). This is unlikely to conflict with general C++ coding skills or testing skills for other languages. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
64%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a solid, actionable skill with excellent executable code examples covering the full GoogleTest/CMake/CTest ecosystem. Its main weaknesses are verbosity (overlapping sections, concepts Claude already knows, lengthy inline configurations) and a lack of explicit validation checkpoints in multi-step workflows like debugging and coverage generation. Splitting detailed reference material into separate files would improve both conciseness and progressive disclosure.
Suggestions
Remove or significantly condense the 'Core Concepts', 'When NOT to Use', and 'Alternatives to GoogleTest' sections — Claude already knows these concepts and they consume tokens without adding actionable value.
Merge the overlapping 'Flaky Tests Guardrails', 'Best Practices', and 'Common Pitfalls' sections into a single concise checklist to eliminate redundancy.
Add explicit validation/verification steps to the debugging workflow (e.g., 'confirm fix by re-running full suite') and coverage workflow (e.g., 'verify coverage threshold meets project requirements').
Move the detailed Coverage and Sanitizers CMake configurations into separate referenced files (e.g., COVERAGE.md, SANITIZERS.md) to keep the main skill lean.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is fairly comprehensive but includes some unnecessary content Claude already knows (e.g., explaining what TDD is, basic concepts like 'mock for interactions, fake for stateful behavior', the 'When NOT to Use' section, and the 'Alternatives to GoogleTest' section). The fixture example includes verbose pseudocode stubs that pad the content. The best practices/pitfalls sections overlap significantly with the flaky tests section. | 2 / 3 |
Actionability | The skill provides fully executable code examples for unit tests, fixtures, mocks, CMake configuration, coverage setup, and sanitizer configuration. The bash commands for building, running tests, and generating coverage reports are copy-paste ready and specific. | 3 / 3 |
Workflow Clarity | The TDD workflow is clearly sequenced (RED → GREEN → REFACTOR), and the debugging section has a reasonable sequence. However, the debugging workflow lacks explicit validation checkpoints — there's no 'verify the fix' step or feedback loop for re-running the full suite after fixing. The coverage and sanitizer sections are configuration-focused without clear validation steps for interpreting results. | 2 / 3 |
Progressive Disclosure | The content is well-structured with clear section headers, but it's a monolithic document (~250 lines) that could benefit from splitting detailed sections (coverage, sanitizers, fuzzing) into separate referenced files. The fuzzing appendix is appropriately marked as optional, but the coverage and sanitizer CMake configurations are lengthy inline content that could be referenced externally. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
Reviewed
Table of Contents