test-driven-development
Use when implementing any feature or bugfix, before writing implementation code
51
38%
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 ./.opencode/skills/test-driven-development/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 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 overly broad scope ('any feature or bugfix') makes it highly prone to conflicts with other development-related skills.
Suggestions
Add explicit capability descriptions: what does this skill do before implementation? (e.g., 'Creates implementation plans, identifies edge cases, designs architecture, and writes test specifications before coding begins')
Narrow the scope or add distinguishing details to reduce conflict risk (e.g., specify the type of planning — architectural design, test-driven development scaffolding, requirements analysis, etc.)
Add a 'Use when...' clause with specific trigger terms like 'plan implementation', 'design before coding', 'pre-implementation checklist', 'break down task' to improve trigger term quality
| 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 states 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 concrete code examples, explicit verification steps, and clear feedback loops for the TDD cycle. However, it is severely undermined by extreme verbosity—roughly half the content is repetitive philosophical argumentation and rationalization rebuttals that Claude doesn't need, with the same core points (delete code, tests-after prove nothing) restated across at least four different sections. Trimming the motivational/argumentative content and moving it to a reference file would dramatically improve this skill.
Suggestions
Remove or consolidate the 'Why Order Matters', 'Common Rationalizations', and 'Red Flags' sections into a single brief section or move them to a separate reference file—they repeat the same 4-5 points multiple times.
Cut explanatory prose that argues why TDD is good; Claude doesn't need persuading. Focus on the 'what to do' (the cycle, verification steps, examples) rather than 'why to do it'.
Move the Good/Bad comparison tables and anti-pattern discussions to a linked reference file (e.g., TDD-PATTERNS.md) to keep the main skill lean.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is extremely verbose at ~300+ lines, with extensive sections on rationalizations, excuses, and philosophical arguments that Claude already understands. The 'Why Order Matters' section, 'Common Rationalizations' table, and 'Red Flags' list are highly repetitive—the same points (delete code, tests-after prove nothing, sunk cost) are restated 3-4 times across different sections. | 1 / 3 |
Actionability | The skill provides fully executable TypeScript code examples for each TDD phase (RED, GREEN, REFACTOR), concrete bash commands for verification, and a complete bug fix walkthrough. Good/Bad comparisons with real code make guidance immediately actionable. | 3 / 3 |
Workflow Clarity | The Red-Green-Refactor cycle is clearly sequenced with explicit verification checkpoints after each phase (Verify RED, Verify GREEN). Feedback loops are well-defined: 'Test passes? Fix test. Test errors? Fix error, re-run.' The verification checklist at the end provides a final validation gate. | 3 / 3 |
Progressive Disclosure | There is one external reference (@testing-anti-patterns.md) which is well-signaled, but the massive amount of inline content (rationalizations, excuses, red flags, philosophy) should be split into a separate reference file. The skill would benefit from being a concise overview with links to detailed argumentation. | 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
- projectbluefin/dakota
- Commit
f062bf8
- 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.