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.
72
43%
Does it follow best practices?
Impact
80%
0.88xAverage score across 8 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.claude/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 skill. The description also uses second person voice ('Use this skill') which is borderline but acceptable since it's directing Claude rather than addressing a user.
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 methodology is explicitly requested or when test coverage is a concern, e.g., 'Use when the user asks for test-driven development, wants tests written alongside code, or needs to improve test coverage.'
Add more distinctive trigger terms related to the skill's unique value: 'TDD', 'test coverage', 'write tests first', 'test-driven', 'coverage threshold', 'testing strategy'.
Rewrite to use third person voice: 'Enforces test-driven development with 80%+ coverage...' instead of 'Use this skill when...', and restructure the 'when' clause accordingly.
| 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 specific concrete 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 a comprehensive but overly verbose TDD guide that explains many concepts Claude already knows (what TDD is, test types, basic best practices). While it provides useful code examples for specific frameworks (Jest, Playwright, Next.js), the content is monolithic and could be dramatically condensed. The workflow lacks proper error recovery feedback loops and the entire document would benefit from splitting into a concise overview with references to detailed pattern files.
Suggestions
Cut the content by at least 50% — remove 'Core Principles', 'When to Activate', 'Best Practices', 'Common Testing Mistakes', and 'Success Metrics' sections as these are generic testing knowledge Claude already has. Focus only on project-specific patterns and conventions.
Add explicit feedback loops to the workflow: after Step 5, include 'If tests fail: read error output, adjust implementation, re-run tests' rather than assuming they pass.
Split mocking patterns, E2E examples, and CI/CD config into separate referenced files (e.g., MOCKING_PATTERNS.md, E2E_EXAMPLES.md) and keep SKILL.md as a concise overview with links.
Replace placeholder comments like '// Test implementation' and '// Implementation here' with actual minimal implementations to make examples fully executable.
| 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, test isolation). The 'Best Practices' and 'Common Testing Mistakes' sections are generic testing knowledge. The 'When to Activate' section restates the obvious. Much of this could be cut by 60%+ without losing actionable value. | 1 / 3 |
Actionability | Contains executable code examples for unit tests, integration tests, E2E tests, and mocking patterns, which is good. However, many examples are semi-generic templates with placeholder comments like '// Test implementation' and '// Implementation here'. The TDD workflow steps themselves are more procedural description than concrete executable guidance specific to a project. | 2 / 3 |
Workflow Clarity | The 7-step TDD workflow is clearly sequenced and includes a coverage verification step. However, there are no explicit validation checkpoints or feedback loops for error recovery — Step 5 just says 'Tests should now pass' with no guidance on what to do if they don't. The workflow lacks a 'fix and re-run' loop, which is critical for TDD. | 2 / 3 |
Progressive Disclosure | Monolithic wall of text with no references to external files. All content — mocking patterns, E2E examples, CI/CD config, coverage thresholds, best practices — is inlined in a single massive document. The mocking examples, testing patterns, and CI/CD integration could easily 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
- sc30gsw/claude-code-customes
- Commit
7aff694
- 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.