tdd-workflow
Use this skill when writing new features, fixing bugs, or refactoring code. Enforces test-driven development with 80%+ coverage including unit, integration, and E2E tests.
60
43%
Does it follow best practices?
Impact
86%
1.07xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./docs/zh-TW/skills/tdd-workflow/SKILL.mdQuality
Discovery
59%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description has good structural completeness with an explicit 'Use when' clause and a clear 'what' statement about TDD enforcement. However, its major weakness is that the trigger conditions are so broad (writing features, fixing bugs, refactoring) that it would conflict with nearly any coding-related skill. The description also uses second person voice ('Use this skill') which is borderline but acceptable as trigger guidance rather than addressing the user directly.
Suggestions
Narrow the trigger conditions to be more specific — instead of 'writing new features, fixing bugs, or refactoring code' (which covers all development), specify when TDD enforcement is specifically needed, e.g., 'Use when the user requests test-driven development, asks for high test coverage, or wants tests written alongside code changes.'
Add more distinctive trigger terms related to the skill's unique value: 'TDD', 'test coverage', 'write tests first', 'test-driven', 'coverage requirements', '80% coverage'.
Rewrite in third person voice: 'Enforces test-driven development with 80%+ coverage...' rather than 'Use this skill when...' as the opening.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (coding) and some actions ('writing new features, fixing bugs, refactoring code') plus mentions TDD and test types, but the actions are fairly generic software development activities rather than concrete, specific capabilities unique to this skill. | 2 / 3 |
Completeness | Explicitly answers both 'what' (enforces test-driven development with 80%+ coverage including unit, integration, and E2E tests) and 'when' ('Use this skill when writing new features, fixing bugs, or refactoring code') with a clear 'Use when' clause. | 3 / 3 |
Trigger Term Quality | Includes some natural keywords like 'features', 'bugs', 'refactoring', 'test-driven development', 'unit', 'integration', 'E2E tests', but these are extremely broad terms that apply to almost any coding task. Missing more specific trigger terms that would help distinguish when this skill should be selected. | 2 / 3 |
Distinctiveness Conflict Risk | The triggers 'writing new features, fixing bugs, or refactoring code' are extremely generic and would match virtually any coding-related request, creating high conflict risk with other coding skills. Almost any development task involves one of these activities. | 1 / 3 |
Total | 8 / 12 Passed |
Implementation
27%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is overly verbose, explaining many concepts Claude already knows (TDD basics, test types, best practices) while providing test examples that are often incomplete with placeholder comments. The content would benefit significantly from being condensed to essential project-specific patterns and splitting detailed examples into referenced files. The workflow is reasonably clear but lacks error recovery loops.
Suggestions
Cut the content by 60%+: remove explanations of TDD principles, test types, and best practices that Claude already knows. Focus only on project-specific patterns, tools, and configuration.
Split mock patterns, E2E examples, and CI/CD config into separate referenced files (e.g., MOCKS.md, E2E_PATTERNS.md) to improve progressive disclosure.
Replace placeholder comments ('// 測試實作', '// 實作在此') with actual executable code examples that demonstrate the specific patterns.
Add explicit feedback loops to the workflow: e.g., 'If coverage < 80%: run coverage report, identify gaps, add tests for uncovered branches, re-run until threshold met.'
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~300+ lines. Explains basic TDD concepts Claude already knows (what unit/integration/E2E tests are, Arrange-Act-Assert, why tests matter). The 'best practices' and 'success metrics' sections are generic knowledge. Many test examples are semi-complete with placeholder comments rather than adding unique value. | 1 / 3 |
Actionability | Provides concrete code examples for test patterns (Jest, Playwright, mocking), but many examples contain placeholder comments like '// 測試實作' and '// 實作在此' rather than executable code. The TDD workflow steps are clear but the implementation step is essentially empty. | 2 / 3 |
Workflow Clarity | The 7-step TDD workflow is clearly sequenced with explicit steps (write test → run failing → implement → run passing → refactor → check coverage). However, there are no validation checkpoints or feedback loops for error recovery — e.g., what to do if coverage is below 80%, or how to handle flaky tests. The coverage verification step lacks a 'fix and retry' loop. | 2 / 3 |
Progressive Disclosure | Monolithic wall of text with everything inline — mock patterns, test organization, CI/CD config, best practices, anti-patterns all in one file. No references to external files for detailed patterns. Content like mock examples, E2E patterns, and CI/CD config should be split into separate reference files. | 1 / 3 |
Total | 6 / 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
- haniakrim21/everything-claude-code
- Commit
ae2cadd
- 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.