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.
Install with Tessl CLI
npx tessl i github:haniakrim21/everything-claude-code --skill tdd-workflow78
Does it follow best practices?
If you maintain this skill, you can automatically optimize it using the tessl CLI to improve its score:
npx tessl skill review --optimize ./path/to/skillValidation for skill structure
Discovery
67%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 structure with explicit 'Use when' guidance and clearly states the TDD enforcement purpose. However, the trigger terms are overly broad (features, bugs, refactoring apply to nearly all coding tasks), which creates high conflict risk with other coding skills. The specific actions enforced by the skill could be more concrete.
Suggestions
Narrow the trigger conditions to be more specific, e.g., 'Use when the user explicitly requests test-driven development, asks for tests to be written first, or mentions coverage requirements'
Add more natural trigger term variations like 'TDD', 'write tests first', 'test coverage', 'testing strategy'
List more concrete actions the skill performs, e.g., 'Writes failing tests before implementation, generates test fixtures, validates coverage thresholds'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names domain (writing features, fixing bugs, refactoring) and mentions TDD with coverage requirements, but lacks specific concrete actions like 'write unit tests', 'generate test fixtures', or 'run coverage reports'. | 2 / 3 |
Completeness | Explicitly answers both what (enforces TDD with 80%+ coverage including unit, integration, E2E tests) and when ('Use this skill when writing new features, fixing bugs, or refactoring code') with clear trigger guidance. | 3 / 3 |
Trigger Term Quality | Includes some relevant terms ('features', 'bugs', 'refactoring', 'test-driven', 'coverage') but these are fairly generic coding terms that could apply to many skills. Missing natural variations like 'TDD', 'write tests', 'testing', 'test coverage'. | 2 / 3 |
Distinctiveness Conflict Risk | The triggers 'writing features', 'fixing bugs', and 'refactoring code' are extremely common coding activities that would likely conflict with general coding skills. The TDD/testing focus provides some distinction but the primary triggers are too broad. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a comprehensive TDD skill with excellent actionable code examples and clear workflow steps. However, it's overly verbose (~400 lines) with content that could be condensed or split into reference files. The skill explains concepts Claude already knows (TDD basics, testing principles) and could be more token-efficient.
Suggestions
Remove explanatory content Claude already knows (e.g., 'Tests are not optional' conclusion, basic TDD principles explanation) to reduce token usage by ~30%
Extract mock patterns, test file organization, and extensive E2E examples into separate reference files (e.g., MOCKS.md, E2E-PATTERNS.md) with links from main skill
Condense the 'Common Test Mistakes' section - the ❌/✅ pattern is good but could use shorter examples
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is comprehensive but overly verbose for Claude. Sections like 'Core Principles' explain TDD basics Claude already knows, and the extensive mock examples could be condensed. The 'Best Practices' list at the end repeats common knowledge. | 2 / 3 |
Actionability | Excellent executable code examples throughout - unit tests with Jest/Vitest, API integration tests, Playwright E2E tests, and mock patterns are all copy-paste ready with realistic implementations. | 3 / 3 |
Workflow Clarity | Clear 7-step TDD workflow with explicit validation checkpoints (Step 3: tests should fail, Step 5: tests should pass, Step 7: verify coverage). The red-green-refactor cycle is well-documented with bash commands for verification. | 3 / 3 |
Progressive Disclosure | Content is well-organized with clear sections, but everything is in one monolithic file. The extensive mock examples, test patterns, and E2E examples could be split into separate reference files with links from the main skill. | 2 / 3 |
Total | 10 / 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
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.