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
Pending
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 explicit 'Use when' guidance and mentions specific testing methodologies, which is good. However, the trigger conditions are overly broad—covering essentially all coding tasks—which would cause this skill to conflict with nearly any other coding-related skill. The description also uses second person ('Use this skill') rather than third person voice, and the 'what it does' portion focuses more on enforcement of a methodology than concrete actions.
Suggestions
Narrow the trigger conditions to be more specific—instead of 'writing new features, fixing bugs, or refactoring code' (which is all coding), specify when TDD enforcement is particularly 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 testing, such as 'TDD', 'test coverage', 'write tests first', 'test suite', 'code coverage threshold' to help differentiate from general coding skills.
Rewrite in third person voice (e.g., 'Enforces test-driven development workflows...') instead of 'Use this skill when...' to follow the expected description style.
| 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. The TDD/testing aspect provides some distinction but the trigger conditions are too generic. | 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 significant tokens explaining TDD fundamentals and generic testing best practices that Claude already knows. While it provides some useful executable code examples (mocking patterns, test patterns), many are incomplete stubs. The content would benefit greatly from aggressive trimming of known concepts and splitting detailed patterns into separate reference files.
Suggestions
Remove sections explaining concepts Claude already knows: 'Core Principles', 'Best Practices' list, 'Success Metrics', 'Common Testing Mistakes to Avoid' (these are standard testing knowledge). Focus only on project-specific conventions and patterns.
Split mocking patterns, E2E test patterns, and CI/CD configuration into separate reference files (e.g., MOCKING.md, E2E_PATTERNS.md) and link to them from the main skill.
Complete the stub examples — Step 4's implementation and the database error test case should have actual executable code rather than placeholder comments.
Add an explicit feedback loop to the workflow: 'If coverage < 80%, run coverage report to identify gaps → add tests for uncovered paths → re-run coverage check.'
| 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, 'tests are not optional'). The 'When to Activate' section, 'Core Principles', 'Best Practices' list, and 'Success Metrics' are largely things Claude inherently understands. The 10-item best practices list is generic testing advice that adds no novel value. | 1 / 3 |
Actionability | Provides executable code examples for unit tests, integration tests, E2E tests, and mocking patterns, which is good. However, many examples are incomplete (e.g., Step 4's implementation is just a stub with '// Implementation here', the database error test has '// Test error handling' placeholder). The workflow steps mix concrete commands with vague instructions like 'Write minimal code to make tests pass'. | 2 / 3 |
Workflow Clarity | The 7-step TDD workflow is clearly sequenced and includes a verification step (Step 7: coverage check). However, there's no feedback loop for when coverage falls below 80% — no explicit 'if coverage < 80%, identify gaps and add tests' step. The workflow also lacks validation checkpoints between steps (e.g., what to do when tests fail unexpectedly in Step 5). | 2 / 3 |
Progressive Disclosure | Monolithic wall of text with no references to external files. Everything — mocking patterns, E2E examples, file organization, CI/CD config, best practices — is inlined in a single massive document. Content like mocking patterns, testing patterns, and CI/CD integration could easily be split into separate reference files. | 1 / 3 |
Total | 6 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
- Repository
- affaan-m/everything-claude-code
- Commit
5df943e
- 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.