jbvc/test-driven-development
Use when implementing any feature or bugfix, before writing implementation code
57
57%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
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 fails to communicate what the skill actually does, only vaguely indicating when it should be used. It lacks any concrete actions, specific capabilities, or distinguishing characteristics that would help Claude select it appropriately from a pool of skills. The description reads more like a partial trigger condition than a complete skill description.
Suggestions
Add explicit capability statements describing what the skill does (e.g., 'Creates implementation plans, identifies edge cases, and outlines test scenarios before coding begins').
Add a clear 'Use when...' clause with specific trigger terms (e.g., 'Use when the user asks to plan a feature, design a solution, create a pre-implementation checklist, or prepare before coding').
Narrow the scope to reduce conflict risk — specify what kind of pre-implementation activity this covers (architecture review, test planning, requirements analysis, etc.) to distinguish it from other development skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description contains no concrete actions whatsoever. It doesn't describe what the skill actually does — 'implementing any feature or bugfix' is extremely vague and 'before writing implementation code' only hints at timing, not capability. | 1 / 3 |
Completeness | The 'when' is partially addressed ('before writing implementation code'), but the 'what' is entirely missing — there is no indication of what this skill actually does. The description only tells when to use it, not what it provides. | 1 / 3 |
Trigger Term Quality | It includes some relevant terms like 'feature', 'bugfix', and 'implementation code' that users might naturally mention, but lacks specificity about what kind of pre-implementation activity this covers (e.g., planning, design, architecture, test writing, spec review). | 2 / 3 |
Distinctiveness Conflict Risk | This description is extremely generic — 'any feature or bugfix' could overlap with virtually every development-related skill. There are no distinct triggers that would help Claude differentiate this from other coding or planning skills. | 1 / 3 |
Total | 5 / 12 Passed |
Implementation
62%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill excels at actionability and workflow clarity with executable examples, clear verification checkpoints, and well-structured TDD phases. However, it is severely bloated by repetitive motivational/argumentative content—the rationalizations, excuses, and 'why order matters' sections repeat the same points in at least three different formats, consuming tokens on persuasion rather than instruction. Roughly half the content could be removed or moved to a supplementary file without losing any actionable guidance.
Suggestions
Remove or consolidate the 'Why Order Matters', 'Common Rationalizations' table, and 'Red Flags' list into a single brief section or move to a separate RATIONALE.md file—they repeat the same arguments in three formats.
Cut explanatory prose that argues for TDD's value (Claude doesn't need convincing) and keep only the procedural instructions and examples.
Move the Good/Bad code comparison tables and anti-pattern guidance to a linked reference file (e.g., TDD-EXAMPLES.md) to keep the main skill under 100 lines.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is extremely verbose at ~300+ lines. It extensively argues why TDD matters, rebuts rationalizations in multiple redundant formats (prose sections, tables, red flags lists), and repeats the same points ('delete means delete', 'tests after prove nothing') many times. Claude already understands TDD concepts; this reads more like a persuasive essay than a concise skill reference. | 1 / 3 |
Actionability | The skill provides fully executable TypeScript code examples for each TDD phase, concrete bash commands for verification, and specific good/bad comparisons. The bug fix walkthrough is copy-paste ready with clear inputs and expected outputs. | 3 / 3 |
Workflow Clarity | The Red-Green-Refactor cycle is clearly sequenced with explicit mandatory verification checkpoints at each stage ('Verify RED - Watch It Fail', 'Verify GREEN - Watch It Pass'). Feedback loops for error recovery are explicit (test passes unexpectedly → fix test; test errors → fix and re-run). The verification checklist at the end provides a final gate. | 3 / 3 |
Progressive Disclosure | There is one external reference (@testing-anti-patterns.md) which is well-signaled, but the bulk of the content is monolithic. The rationalizations section, common excuses table, red flags list, and 'Why Order Matters' section could all be in a separate reference file, keeping the main skill lean. Much inline content should be split out. | 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.
Reviewed
Table of Contents