CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

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.

1.07x
Quality

73%

Does it follow best practices?

Impact

89%

1.07x

Average score across 3 eval scenarios

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/tdd-workflow/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

56%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The content delivers a clear, checkpoint-driven TDD workflow with mostly executable code examples, but it is padded with substantial generic testing material Claude already knows and crams everything into one long file with no progressive disclosure. The strongest material is the app-specific mocking patterns and coverage configuration; the weakest is the verbose re-teaching of standard testing practices.

Suggestions

Cut or drastically compress the generic sections — Button unit tests, 'Common Testing Mistakes', and the 'Best Practices' list — keeping only what is specific to this project's conventions, since Claude already knows standard Jest/Playwright practice.

Split the E2E Playwright patterns, service-specific mocks (Supabase/Redis/OpenAI), and coverage/CI configuration into separate reference files (e.g., references/e2e-patterns.md, references/mocks.md) linked from a lean overview.

Add an explicit error-recovery loop after the coverage verification step (e.g., 'if coverage < 80%, list uncovered branches and add tests before proceeding') to close the workflow's feedback gap.

DimensionReasoningScore

Conciseness

Several full sections restate testing knowledge Claude already has: the generic Button component Jest tests, the "Common Testing Mistakes" do/don't pairs (brittle selectors, test isolation), and the 10-item "Best Practices" list (Arrange-Act-Assert, descriptive test names, test edge cases). It is not level 3 because the padding spans multiple sections rather than isolated over-explanations; not level 1 because there is no concept-tutorial prose and the app-specific material (Supabase/Redis/OpenAI mocks, coverage thresholds) is genuinely non-obvious.

2 / 5

Actionability

Mostly executable guidance: complete Jest/Vitest and Playwright test code, concrete commands (`npm test`, `npm run test:coverage`), a coverageThresholds JSON config, and CI YAML. It is not level 5 because several examples are placeholder skeletons — "// Test implementation", "// Mock database failure" with no mock code, and `export async function searchMarkets(query: string) { // Implementation here }`; not level 3 because the pattern sections provide complete, runnable code.

4 / 5

Workflow Clarity

The 7-step TDD workflow is clearly sequenced with explicit checkpoints at each phase: "Tests should fail - we haven't implemented yet", "Tests should now pass", and "Verify 80%+ coverage achieved". It is not level 5 because there is no error-recovery guidance (e.g., what to do when coverage is still below 80% or tests fail after implementation); not level 3 because validation checkpoints are explicit rather than implicit.

4 / 5

Progressive Disclosure

Section headers are well-organized and in-file navigation is easy, but the ~400-line body has no bundle files at all — the E2E Playwright patterns, per-service mocking recipes, and coverage config clearly belong in separate reference files. It is not level 4 because content that should be split out is entirely inline with no references; not level 2 because the internal structure is solid, not minimal.

3 / 5

Total

13

/

20

Passed

Description

80%Weight 40%Scale 1-5

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 cleanly answers both what the skill does and when to use it, with a concrete coverage threshold and named test types. Its main weaknesses are trigger breadth — the when-clause fires on essentially all coding tasks — and missing common trigger synonyms like 'TDD' and 'test coverage'. Overall a strong, above-midpoint description.

Suggestions

Narrow the when-clause to testing-relevant moments (e.g., 'when the user asks for tests, test coverage, or TDD, or when implementing changes that must meet coverage gates') to reduce conflict with general coding and refactoring skills.

Add the 'TDD' acronym and natural trigger phrases like 'write tests' or 'test coverage' to catch users who use those terms.

DimensionReasoningScore

Specificity

"Enforces test-driven development with 80%+ coverage including unit, integration, and E2E tests" names concrete specifics — a methodology, a numeric threshold, and three test categories — which goes beyond the 1-2 actions of the level-3 anchor. It is not level 5 because the skill's actions collapse into a single 'enforces' verb rather than multiple distinct concrete actions.

4 / 5

Completeness

Both halves are explicit: 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 concrete trigger phrases. It is not level 4 because the when-clause is already explicit and specific, matching the level-5 anchor structure.

5 / 5

Trigger Term Quality

"writing new features, fixing bugs, or refactoring code" are natural phrases users would actually say when needing this skill. It is not level 5 because common variations are missing — the 'TDD' acronym, 'write tests', and 'test coverage' as standalone trigger terms; not level 3 because the natural-term coverage of development scenarios is good.

4 / 5

Distinctiveness Conflict Risk

The TDD/testing focus ("80%+ coverage", "unit, integration, and E2E tests") is a recognizable niche, but the triggers "writing new features, fixing bugs, or refactoring code" cover nearly all development work, creating overlap risk with general coding, review, and refactoring skills. It is not level 4 because the trigger breadth is a real conflict risk; not level 2 because the testing niche keeps it distinguishable from non-testing skills.

3 / 5

Total

16

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository

valeriibeck-star/claude-skills

Path

skills/tdd-workflow/SKILL.md

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.