cpp-testing
C++ テストの作成/更新/修正、GoogleTest/CTest の設定、失敗またはフレーキーなテストの診断、カバレッジ/サニタイザーの追加時にのみ使用します。
87
82%
Does it follow best practices?
Impact
92%
1.22xAverage score across 3 eval scenarios
Passed
No known issues
Quality
Discovery
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.
This is a strong, well-crafted skill description that clearly defines its scope around C++ testing workflows. It lists specific concrete actions, includes natural trigger terms (GoogleTest, CTest, flaky, sanitizer, coverage), and explicitly states when to use it with the '〜時にのみ使用します' clause. The description is concise yet comprehensive, with a distinct niche that minimizes conflict risk.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: creating/updating/fixing C++ tests, configuring GoogleTest/CTest, diagnosing failing or flaky tests, and adding coverage/sanitizers. | 3 / 3 |
Completeness | Clearly answers both 'what' (C++ test creation/update/fix, GoogleTest/CTest configuration, diagnosing failures, adding coverage/sanitizers) and 'when' with the explicit trigger clause '〜時にのみ使用します' (use only when...), which serves as an explicit 'Use when' directive. | 3 / 3 |
Trigger Term Quality | Includes strong natural trigger terms users would say: 'C++ テスト' (C++ test), 'GoogleTest', 'CTest', 'フレーキー' (flaky), 'カバレッジ' (coverage), 'サニタイザー' (sanitizer). These cover the key terms a user working with C++ testing would naturally use. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with a clear niche: C++ testing specifically with GoogleTest/CTest, flaky test diagnosis, and sanitizer/coverage tooling. The scope is narrow and well-defined, unlikely to conflict with general coding or other language testing skills. | 3 / 3 |
Total | 12 / 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 comprehensive C++ testing skill with strong actionability—executable code examples, complete CMake configurations, and specific CLI commands. However, it suffers from verbosity (redundant sections, concepts Claude already knows) and could benefit from better progressive disclosure by splitting detailed coverage/sanitizer/fuzzing content into separate files. Workflow clarity is adequate but missing explicit validation checkpoints in multi-step processes like coverage generation and debugging.
Suggestions
Remove redundant content: the flaky test guidance appears in both 'Flaky Test Guardrails' and 'Common Pitfalls' sections; merge them. Also trim explanations of basic concepts (TDD definition, mock vs fake distinction) that Claude already knows.
Add explicit validation checkpoints to multi-step workflows—e.g., after coverage generation, verify the .profraw/.gcda files exist; after sanitizer builds, confirm sanitizer is active with a known-bad test.
Split coverage, sanitizer, and fuzzing sections into separate referenced files (e.g., COVERAGE.md, SANITIZERS.md, FUZZING.md) to reduce the main skill's token footprint and improve progressive disclosure.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is fairly comprehensive but includes some unnecessary content Claude already knows (e.g., explaining TDD loop concepts, what mocks vs fakes are, basic best practices like 'keep tests deterministic'). The 'When to use / When not to use' section and repeated flaky test guidance (appears in both 'Flaky Test Guardrails' and 'Common Pitfalls') add redundancy. The code examples are useful but the overall document could be tightened significantly. | 2 / 3 |
Actionability | The skill provides fully executable code examples for unit tests, fixtures, mocks, CMake configuration, coverage setup (both GCC and Clang), sanitizer configuration, and fuzzing harnesses. Commands are copy-paste ready with specific flags and paths. The CMake/CTest quickstart is complete and buildable. | 3 / 3 |
Workflow Clarity | The TDD workflow (RED → GREEN → REFACTOR) is clearly sequenced, and the debugging section has a reasonable 4-step process. However, the debugging workflow lacks explicit validation checkpoints (e.g., 'verify the fix by re-running the specific test before expanding'). The coverage workflow lists commands sequentially but doesn't include verification steps to confirm coverage data was generated correctly. | 2 / 3 |
Progressive Disclosure | The content is well-structured with clear section headers, but it's a monolithic document (~250 lines) with no references to external files. The coverage section, sanitizer configuration, fuzzing appendix, and detailed mock examples could be split into separate reference files. For a skill of this complexity, inline content is excessive without bundle support. | 2 / 3 |
Total | 9 / 12 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 — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- affaan-m/everything-claude-code
- Commit
841beea
- 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.