Test-driven development skill for writing unit tests, generating test fixtures and mocks, analyzing coverage gaps, and guiding red-green-refactor workflows across Jest, Pytest, JUnit, Vitest, and Mocha. Use when the user asks to write tests, improve test coverage, practice TDD, generate mocks or stubs, or mentions testing frameworks like Jest, pytest, or JUnit.
74
67%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./engineering-team/tdd-guide/SKILL.mdQuality
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 an excellent skill description that hits all the marks. It provides specific concrete actions, comprehensive trigger terms that users would naturally use, a clear 'Use when...' clause, and a well-defined niche around testing and TDD. The description is concise yet thorough, using proper third-person voice throughout.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: writing unit tests, generating test fixtures and mocks, analyzing coverage gaps, and guiding red-green-refactor workflows. Also names specific frameworks (Jest, Pytest, JUnit, Vitest, Mocha). | 3 / 3 |
Completeness | Clearly answers both 'what' (writing unit tests, generating fixtures/mocks, analyzing coverage gaps, guiding TDD workflows) and 'when' (explicit 'Use when...' clause listing multiple trigger scenarios including writing tests, improving coverage, practicing TDD, generating mocks, or mentioning specific frameworks). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural terms users would say: 'write tests', 'test coverage', 'TDD', 'mocks', 'stubs', 'Jest', 'pytest', 'JUnit', 'testing frameworks'. These are all terms users would naturally use when seeking testing help. | 3 / 3 |
Distinctiveness Conflict Risk | Clearly carved out niche around test-driven development and testing specifically. The mention of specific frameworks, TDD workflows, mocks/stubs, and coverage analysis makes it highly distinct and unlikely to conflict with general coding or other development skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
35%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill covers TDD comprehensively with good code examples across multiple languages and clear workflow structures. However, it is significantly over-verbose, explaining concepts Claude already knows (mutation testing rationale, property-based testing concepts) and inlining content that should be in separate files. The core tooling (test_generator.py, coverage_analyzer.py) is referenced but not provided, undermining true actionability.
Suggestions
Move property-based testing, mutation testing, and per-language examples into separate referenced files (e.g., PROPERTY_TESTING.md, MUTATION_TESTING.md, EXAMPLES.md) to reduce the main skill to an overview with links.
Remove explanatory content Claude already knows—e.g., 'Mutation testing modifies your production code...', 'Property-based testing generates random inputs...'—and keep only the actionable patterns and commands.
Clarify whether test_generator.py, coverage_analyzer.py, and tdd_workflow.py are actual scripts that exist in the project or conceptual placeholders; if they don't exist, replace with real framework commands (e.g., pytest, jest --coverage).
Add explicit error-recovery steps to workflows—e.g., what to do when test_generator.py produces incorrect stubs, or when coverage_analyzer.py reports parsing errors.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is extremely verbose at ~300+ lines. It includes extensive sections on property-based testing, mutation testing, Go table-driven tests, and cross-references that bloat the content well beyond what's needed. Many concepts (what mutation testing is, why it matters, what property-based testing is) are things Claude already knows. The cross-references table and limitations table add tokens without much actionable value. | 1 / 3 |
Actionability | The skill provides concrete code examples across multiple languages and frameworks, which is good. However, the core tools referenced (test_generator.py, coverage_analyzer.py, tdd_workflow.py, fixture_generator.py) appear to be custom scripts that aren't provided or explained—Claude can't actually execute them. The examples are illustrative but the tool commands are not truly executable without those scripts existing. | 2 / 3 |
Workflow Clarity | The three workflows (Generate Tests, Analyze Coverage, TDD New Feature) are clearly sequenced with validation steps mentioned. However, the validation steps are vague ('Tests compile and cover happy path, error cases, edge cases') rather than explicit commands. The TDD workflow references tdd_workflow.py phases but doesn't explain what happens if validation fails in a concrete way—no real feedback loops for error recovery. | 2 / 3 |
Progressive Disclosure | The skill has good section structure with clear headers and a tools table. However, it's a monolithic document that inlines extensive content (property-based testing, mutation testing, multi-language examples) that should be in separate referenced files. The cross-reference to engineering/spec-driven-workflow is good, but the bulk of advanced content should be split out rather than included inline. | 2 / 3 |
Total | 7 / 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.
f567c61
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.