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.

56

Quality

63%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./docs/zh-TW/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, actionable TDD sequence with genuinely useful project-specific test patterns, but it is roughly twice as long as it needs to be because much of it re-states standard testing knowledge Claude already has. Splitting the generic patterns and configuration into reference files would fix both the verbosity and the monolithic structure.

Suggestions

Cut or externalize the sections that re-teach standard knowledge — the generic Button unit-test example, the '常見測試錯誤避免' mistakes primer, and the 10-item '最佳實務' list — keeping only project-specific conventions Claude could not infer.

Move the test patterns (單元/整合/E2E examples), mock recipes (Supabase/Redis/OpenAI), and coverage/CI configuration into references/ files (e.g., references/test-patterns.md, references/mocks.md), leaving SKILL.md as a concise workflow overview with well-signaled one-level-deep links.

Fill in the placeholder test bodies in step 2 and the empty error-path test in the API integration example so all guidance is copy-paste executable, and add an explicit recovery step when coverage falls below the 80% gate.

DimensionReasoningScore

Conciseness

The ~400-line body spends large sections re-teaching what Claude already knows: a generic Button testing-library example, standard Playwright idioms, a 10-item generic best-practices list, and a 'common testing mistakes' section explaining basic principles like test isolation and semantic selectors. It is noticeably verbose with several padded sections, though the project-specific mocks and semantic-search examples are genuinely additive — above anchor 1's wholly redundant example.

2 / 5

Actionability

Most guidance is executable: 'npm test', 'npm run test:coverage', a concrete Jest coverageThresholds config, CI YAML, and copy-paste mock code for Supabase/Redis/OpenAI. Minor gaps remain — step 2's test cases are placeholder bodies ('// 測試實作') and the 'handles database errors gracefully' test is empty — so it does not reach fully copy-paste-ready anchor 5.

4 / 5

Workflow Clarity

The 7-step TDD workflow is clearly sequenced with expected-outcome checkpoints (tests should fail at step 3, pass at step 5, and coverage ≥80% at step 7), forming an implicit feedback loop. It lacks explicit error-recovery guidance ('if coverage falls short, do X'), which anchor 5 requires.

4 / 5

Progressive Disclosure

The body has good section structure, but there are no bundle files at all — roughly 400 lines in a single SKILL.md where the test patterns, mock recipes, and coverage/CI configuration clearly belong in separate reference files. It sits at 'some structure but content that should be separate is inline' rather than anchor 2, since headers make navigation possible.

3 / 5

Total

13

/

20

Passed

Description

71%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 is well-formed with an explicit what-and-when structure and natural trigger phrases. Its main weakness is breadth: it claims the entire feature/bugfix/refactor space, and its 'what' reduces to a single enforcement action rather than a set of distinct capabilities.

Suggestions

Narrow the trigger conditions to moments where TDD discipline actually applies (e.g., 'Use when adding a feature or bug fix that needs new tests, when the user asks for TDD or test coverage, or when tests must reach the 80% coverage gate') to reduce conflict with general coding skills.

Enumerate the concrete actions the skill performs (e.g., 'Generates unit/integration/E2E test cases, configures Jest/Playwright coverage thresholds, mocks Supabase/Redis/OpenAI dependencies') instead of the single verb 'Enforces'.

Add common trigger synonyms users actually say — 'add tests', 'write tests', 'test coverage', 'TDD' — to improve trigger-term coverage.

DimensionReasoningScore

Specificity

The description names the domain and concrete specifics ('Enforces test-driven development with 80%+ coverage including unit, integration, and E2E tests') but lists essentially one enforcement action rather than several distinct concrete actions, matching the 'names domain and 1-2 concrete actions' anchor rather than the 'lists several specific actions' anchor above.

3 / 5

Completeness

It 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 concrete trigger phrases, matching the top anchor; the 'when' is specific, not weakly implied.

5 / 5

Trigger Term Quality

'writing new features, fixing bugs, refactoring code' are natural phrases users would say, giving good keyword coverage; common variations such as 'add tests', 'write a test for', or 'test coverage' are missing, so it falls just below the comprehensive-synonyms anchor.

4 / 5

Distinctiveness Conflict Risk

Triggering on all new-feature work, bug fixes, and refactoring covers virtually every coding task, creating high overlap risk with general coding and review skills — the 'very broad; high overlap risk with many similar skills' anchor. It is not entirely generic (TDD and 80% coverage give it some identity), so it does not fall to 1.

2 / 5

Total

14

/

20

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 — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
affaan-m/ECC
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.