tdg-personal/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.
59
59%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
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
39%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill has a well-structured TDD workflow with clear validation checkpoints and git commit conventions, which is its strongest aspect. However, it is severely bloated with generic testing knowledge Claude already possesses (test isolation, AAA pattern, semantic selectors, best practices lists), and all content is crammed into a single file with no progressive disclosure. The content would benefit enormously from being trimmed to ~30% of its current size and splitting reference material into linked files.
Suggestions
Remove sections that teach general testing knowledge Claude already knows: 'Common Testing Mistakes to Avoid', 'Best Practices' list, 'Success Metrics', and the explanations of what unit/integration/E2E tests are. Keep only the TDD workflow steps and project-specific conventions.
Extract the testing patterns (unit, integration, E2E), mocking examples, and file organization into separate referenced files (e.g., TESTING_PATTERNS.md, MOCKING.md) and link to them from a concise overview section.
Consolidate the verbose RED/GREEN gate definitions into a compact checklist or decision table rather than multi-paragraph prose with bullet sub-points.
Remove or drastically shorten the 'When to Activate' section—the YAML description already covers this, and listing 'Writing new features', 'Fixing bugs', 'Refactoring' is obvious given the skill's purpose.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~350+ lines. Explains basic testing concepts Claude already knows (what unit/integration/E2E tests are, Arrange-Act-Assert, test isolation). The 'Best Practices' list, 'Common Testing Mistakes', and 'Success Metrics' sections are all general testing knowledge that adds no novel value. Mocking examples for specific services (Supabase, Redis, OpenAI) are overly specific yet simultaneously not reusable. | 1 / 3 |
Actionability | Contains executable code examples (TypeScript tests, bash commands, Jest config), but many are generic templates rather than truly actionable guidance. The test patterns are illustrative but tied to a specific project context (markets, Supabase, Redis) without being universally applicable. The TDD workflow steps are concrete but the RED/GREEN gate definitions are overly legalistic rather than practically executable. | 2 / 3 |
Workflow Clarity | The 7-step TDD workflow is clearly sequenced with explicit validation checkpoints (RED gate at Step 3, GREEN validation at Step 5, coverage verification at Step 7). Git checkpoint commits are well-defined with feedback loops (compile-time vs runtime RED, re-validate before proceeding). The workflow includes clear error recovery guidance and explicit gates preventing premature progression. | 3 / 3 |
Progressive Disclosure | Monolithic wall of text with no references to external files. All content—workflow steps, testing patterns, mocking examples, file organization, CI/CD config, best practices—is inlined in a single document. The mocking examples, test patterns, and file organization sections should be split into separate reference files with clear navigation links. | 1 / 3 |
Total | 7 / 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 | |
Reviewed
Table of Contents