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.
54
43%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.agents/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 a clear structure with an explicit 'Use when' clause and mentions specific testing methodology (TDD, 80%+ coverage, test types), which is good. However, the trigger conditions are far too broad—essentially any coding task would match—creating significant conflict risk with other skills. The description also uses second person voice ('Use this skill') rather than third person, and the actual capabilities of the skill beyond enforcing TDD are unclear.
Suggestions
Narrow the trigger conditions to be more specific—instead of 'writing new features, fixing bugs, or refactoring code' (which covers nearly all development), specify when TDD enforcement is particularly needed, e.g., 'Use when the user requests test-driven development, wants high test coverage, or asks for tests alongside code changes.'
Add more specific concrete actions the skill performs, e.g., 'Writes failing tests before implementation, generates test suites with unit/integration/E2E coverage, enforces 80%+ code coverage targets, and structures code for testability.'
Rewrite in third person voice (e.g., 'Enforces test-driven development...' rather than 'Use this skill when...') and add distinguishing trigger terms like 'TDD', 'test coverage', 'test-first', 'testing workflow'.
| 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 of the skill itself. | 2 / 3 |
Completeness | Explicitly answers both 'what' (enforces TDD 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 broad 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 excessively verbose, spending most of its token budget on general TDD knowledge and testing best practices that Claude already knows. While it provides some useful executable code patterns (mocking, test structure), the content would benefit enormously from being trimmed to project-specific guidance and split across referenced files. The workflow section is reasonable but lacks error recovery feedback loops.
Suggestions
Cut the content by 60-70%: remove 'Core Principles', 'Best Practices', 'Common Testing Mistakes', and 'Success Metrics' sections — Claude already knows standard TDD practices. 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, fix implementation, re-run tests' rather than assuming they pass.
Extract mocking patterns, test file organization, and CI/CD config into separate referenced files (e.g., MOCKING_PATTERNS.md, TEST_ORGANIZATION.md) to improve progressive disclosure.
Replace placeholder comments like '// Test implementation' and '// Test error handling' with actual executable test code to improve actionability.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~300+ lines. Explains basic TDD concepts, testing principles, and best practices that Claude already knows well. The 'Core Principles' section, 'Common Testing Mistakes to Avoid', and 'Best Practices' list are all general knowledge. The motivational closing line ('Tests are not optional...') adds zero value. | 1 / 3 |
Actionability | Contains executable code examples for unit tests, integration tests, E2E tests, and mocking patterns, which is good. However, much of it is semi-generic template code (e.g., the Button component test, the Playwright tests) rather than project-specific executable guidance. Step 4 ('Write minimal code to make tests pass') is vague, and several test bodies contain only comments like '// Test implementation'. | 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 and no bundle files to support it. All content — mocking patterns, test organization, CI/CD config, best practices — is inlined when much of it could be split into separate reference files. No navigation structure or signposting for different sections. | 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
- affaan-m/everything-claude-code
- Commit
841beea
- 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.