write-tests
Guide for writing tests in the project
24
14%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.agents/skills/write-tests/SKILL.mdQuality
Discovery
14%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 description is essentially a title rather than a functional skill description. It lacks concrete actions, explicit trigger conditions, and natural keyword variations, making it nearly impossible for Claude to reliably select this skill from a pool of alternatives. It would benefit significantly from specifying what kinds of tests, what frameworks or patterns are covered, and when to invoke it.
Suggestions
Add a 'Use when...' clause with explicit trigger terms, e.g., 'Use when the user asks to write tests, create test cases, add unit tests, or generate test coverage for project code.'
List specific concrete actions the skill covers, e.g., 'Creates unit tests, integration tests, and test fixtures following project conventions. Handles mocking, assertions, and test organization.'
Include natural keyword variations users might say, such as 'unit test', 'integration test', 'spec', 'test file', 'test coverage', 'TDD', and any relevant framework names (e.g., Jest, pytest, RSpec).
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description is extremely vague — 'writing tests' names a broad domain but no concrete actions like 'create unit tests', 'mock dependencies', 'generate test fixtures', or 'write integration tests'. It reads more like a document title than a capability description. | 1 / 3 |
Completeness | The description weakly addresses 'what' (guide for writing tests) and completely omits 'when' — there is no 'Use when...' clause or any explicit trigger guidance, which per the rubric caps completeness at 2, and the 'what' itself is too vague to even reach that level. | 1 / 3 |
Trigger Term Quality | The term 'tests' is a natural keyword users might say, but the description lacks common variations such as 'unit tests', 'integration tests', 'test cases', 'testing', 'specs', 'assertions', or framework-specific terms that would improve matching. | 2 / 3 |
Distinctiveness Conflict Risk | The description is so generic that it could conflict with any skill related to code quality, linting, CI/CD, or development workflows. 'Writing tests in the project' provides no distinguishing niche or specific triggers. | 1 / 3 |
Total | 5 / 12 Passed |
Implementation
14%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides a rough outline for writing tests but falls short on nearly every dimension. It lacks concrete code examples for the core testing pattern (FP32 vs FP64 comparison), contains multiple typos, references examples without providing paths or links, and has no validation checkpoints in the workflow. The skill would benefit significantly from a complete worked example and proper file references.
Suggestions
Add a complete, executable example showing the FP32 vs FP64 comparison pattern in both the main.cpp and the corresponding pytest file, so Claude can follow the pattern concretely.
Provide explicit file paths to the referenced example tests (test_fp32_dot_product, etc.) and include a Makefile template or link to one instead of saying 'see the examples'.
Add validation checkpoints: after building, verify the clang tool instrumented correctly; after running pytest, describe expected output for pass/fail cases.
Fix typos ('theese', 'extesion', 'Mkefile', 'Enssure') and restructure the content with clear sections: Directory Structure, Test Pattern, Build, Run, Environment Setup.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is relatively brief and doesn't over-explain concepts Claude already knows, but it contains some unnecessary filler (e.g., 'follow theese', vague phrasing like 'For now, only write tests in FP32 precision') and has multiple typos ('theese', 'extesion', 'Mkefile', 'Enssure') that reduce clarity without adding value. | 2 / 3 |
Actionability | The guidance is mostly vague and abstract: 'write your test cases using pytest', 'see the examples', 'see the examples' for Makefile building. There are no concrete code snippets showing how to structure a test, no example of the FP32 vs FP64 comparison pattern, and no executable Makefile template. The only concrete commands are the bash commands for running tests and activating the environment. | 1 / 3 |
Workflow Clarity | The steps are loosely ordered but lack clear sequencing for the full workflow (create directory → write C++ → write pytest → build Makefile → instrument → run). There are no validation checkpoints, no feedback loops for when tests fail unexpectedly, and the relationship between the C++ file and the pytest file is not clearly explained. The 'To build the Mkefile, see the examples' is a dead-end instruction. | 1 / 3 |
Progressive Disclosure | References to examples (test_fp32_dot_product, test_fp32_average, test_fp32_nested_loop) are mentioned but not linked or given paths. 'See the examples' for Makefile building provides no path or file reference. There are no bundle files to support these references, and the content is a flat list with poor structural organization (the '## Enssure' section is oddly placed and formatted). | 1 / 3 |
Total | 5 / 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
- llnl/FPChecker
- Commit
875a03e
- 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.