Generate comprehensive unit tests for a Spark UI component using Vitest and React Testing Library. Use when the user wants to add tests, improve test coverage, or test a specific component.
60
70%
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 ./.cursor/skills/generate-tests/SKILL.mdQuality
Discovery
89%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 solid skill description that clearly identifies its purpose, technology stack, and when to use it. The explicit 'Use when' clause with multiple trigger scenarios is well done. The main weakness is that the 'what' portion could be more specific about the types of tests or testing patterns it generates rather than relying on the vague qualifier 'comprehensive'.
Suggestions
Replace 'comprehensive unit tests' with more specific actions, e.g., 'Generate unit tests covering rendering, user interactions, props validation, and edge cases for Spark UI components'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | It names the domain (Spark UI component testing) and mentions the tools (Vitest, React Testing Library), but the action is singular and somewhat generic ('generate comprehensive unit tests') rather than listing multiple specific concrete actions like 'test rendering, user interactions, edge cases, accessibility'. | 2 / 3 |
Completeness | Clearly answers both 'what' (generate comprehensive unit tests for Spark UI components using Vitest and RTL) and 'when' (explicit 'Use when' clause covering adding tests, improving coverage, or testing a specific component). | 3 / 3 |
Trigger Term Quality | Includes strong natural trigger terms users would say: 'unit tests', 'test coverage', 'test a specific component', 'Vitest', 'React Testing Library', 'Spark UI'. These cover common variations of how users would request testing help for this stack. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive due to the specific technology stack (Spark UI, Vitest, React Testing Library). The combination of these specific tools and the 'unit tests' focus creates a clear niche unlikely to conflict with other skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
50%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 reasonable starting template for generating Spark UI component tests but falls short on actionability and workflow clarity. The code example is incomplete (empty accessibility test, undefined defaultProps), the 'What to Test' section is generic knowledge Claude already possesses, and there's no explicit validation step to run tests and verify they pass after generation.
Suggestions
Complete the code example with a fully executable test including a real accessibility test body and defined defaultProps, so Claude can copy-paste and adapt rather than fill in blanks.
Add an explicit validation step after test generation: 'Run `npm run test:run` and verify all tests pass. If failures occur, read the error output and fix the failing assertions before proceeding.'
Remove or significantly trim the 'What to Test' checklist and 'When to Use' section — Claude already knows what unit tests should cover and can detect user intent without trigger-word lists.
Replace the vague 'Reference existing test files' line with a concrete example of a well-written test from the project, or point to a specific file path if one exists in the bundle.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient but includes some unnecessary content like the 'When to Use' section (trigger detection is not actionable guidance for Claude) and the 'What to Test' section is a generic checklist that Claude already knows. The code example earns its place but could be tighter. | 2 / 3 |
Actionability | Provides a concrete code template for test structure and specific commands for running tests, but the test example is incomplete (the accessibility test body is empty, defaultProps is undefined). The 'What to Test' section is a vague checklist rather than concrete examples. The reference to existing test files is hand-wavy rather than pointing to a specific file. | 2 / 3 |
Workflow Clarity | Steps are listed but there's no validation checkpoint or feedback loop. For a test-generation workflow, there should be an explicit step to run the tests after writing them and verify they pass, with guidance on what to do if tests fail. The numbered steps are more of a reference list than a sequential workflow. | 2 / 3 |
Progressive Disclosure | The content is reasonably structured with clear sections, but the reference to 'existing test files in packages/components/src/*/ComponentName.test.tsx' is vague and no bundle files are provided to support it. Some content like the full 'What to Test' checklist could be in a separate reference file if it were more detailed, but as-is it's borderline appropriate inline. | 2 / 3 |
Total | 8 / 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.
76a3678
Table of Contents
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.