CtrlK
BlogDocsLog inGet started
Tessl Logo

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.

43

Quality

43%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./.agents/skills/tdd-workflow/SKILL.md
SKILL.md
Quality
Evals
Security

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 a clear 'Use when' clause and mentions TDD enforcement with specific test types, which is good for completeness. However, the trigger conditions are so broad (any feature, bug fix, or refactoring) that it would conflict with almost every other coding skill. The description also uses second person voice ('Use this skill') rather than third person, and lacks specificity about what concrete actions the skill performs beyond enforcing TDD.

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.'

Rewrite in third person voice: e.g., 'Enforces test-driven development workflows with 80%+ coverage...' instead of 'Use this skill when...'

Add more concrete actions the skill performs, such as 'Generates test scaffolds before implementation, runs coverage analysis, creates unit/integration/E2E test suites' to improve specificity.

DimensionReasoningScore

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 concrete, specific capabilities unique to this skill.

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'). The 'Use when' clause is present and explicit.

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

Extremely generic scope — 'writing new features, fixing bugs, or refactoring code' covers virtually all software development tasks, meaning this skill would conflict with nearly any other coding-related skill. The TDD aspect adds some distinction but the trigger conditions are far too broad.

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 teaching Claude things it already knows (TDD principles, testing best practices, common mistakes). While it provides some concrete code examples, many contain placeholder comments rather than complete implementations. The monolithic structure with no progressive disclosure makes it an inefficient use of context window space.

Suggestions

Reduce content by 60-70% by removing sections Claude already knows: Core Principles, Best Practices list, Success Metrics, Common Testing Mistakes, and the motivational closing. Focus only on project-specific conventions and patterns.

Split mocking patterns, CI/CD configuration, and coverage thresholds into separate reference files (e.g., MOCKING.md, CI.md) and link to them from a concise overview.

Add explicit feedback loops in the workflow: what to do when coverage is below 80%, how to handle tests failing for unexpected reasons, and recovery steps for common failure modes.

Replace placeholder comments like '// Test implementation' and '// Implementation here' with actual minimal executable code to improve actionability.

DimensionReasoningScore

Conciseness

Extremely verbose at ~300+ lines. Explains basic TDD concepts, testing principles, and best practices that Claude already knows well. Sections like 'Core Principles', 'Best Practices' (10-item list), 'Success Metrics', and 'Common Testing Mistakes to Avoid' are all standard knowledge. The closing motivational line is pure padding.

1 / 3

Actionability

Provides concrete code examples for unit, integration, and E2E tests that are mostly executable, but many are incomplete (e.g., 'Test implementation' comments, 'Implementation here' placeholders). The workflow steps are somewhat generic ('Write minimal code to make tests pass') rather than providing truly specific, copy-paste-ready guidance for a particular project context.

2 / 3

Workflow Clarity

The 7-step TDD workflow is clearly sequenced with verification steps (run tests, verify coverage), but lacks explicit error recovery/feedback loops. Step 3 says 'tests should fail' but doesn't address what to do if they fail for the wrong reasons. Step 7 doesn't specify what to do if coverage is below 80%. Missing validation checkpoints for destructive or batch operations.

2 / 3

Progressive Disclosure

Monolithic wall of text with no references to external files and no bundle files. All content—mocking patterns, test organization, CI/CD config, best practices, common mistakes—is inlined in a single massive document. Much of this content (mocking examples, CI/CD yaml, coverage config) should 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.

Validation11 / 11 Passed

Validation for skill structure

No warnings or errors.

Repository
affaan-m/everything-claude-code
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.