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.

Quality

66%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

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

Quality

Content

65%Weight 40%Scale 1-3

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

The skill is strongly actionable with rich executable, project-specific examples and a clear TDD sequence, but it is overlong for a single file, restates testing concepts Claude already knows, and lacks explicit error-recovery feedback loops.

Suggestions

Move the test-pattern catalog, mock recipes, and CI/coverage config into separate reference files (e.g., TEST-PATTERNS.md, MOCKS.md) and keep SKILL.md as a lean overview with one-level-deep links, improving both conciseness and progressive disclosure.

Make the error-recovery feedback explicit at each checkpoint (e.g., 'Step 5: run tests; if any fail, return to Step 4 and fix the implementation before refactoring; Step 7: if coverage < 80%, add tests for the uncovered branches').

Cut the generic best-practices list and test-type definitions that restate knowledge Claude already has; keep only project-specific guidance such as the Supabase/Redis/OpenAI mock shapes and the file-organization convention.

Dimension	Reasoning	Score
Conciseness	The body contains real executable content, but it is padded with general testing knowledge Claude already knows—test-type definitions, a 10-item best-practices list, and a common-mistakes primer re-explaining test isolation and semantic selectors.	2 / 3
Actionability	It provides extensive concrete, executable, project-specific code and commands—Jest/Vitest unit tests, Next.js API integration tests, full Playwright E2E specs, Supabase/Redis/OpenAI mocks, coverage-threshold JSON, and CI YAML—that are copy-paste ready.	3 / 3
Workflow Clarity	The 7-step TDD sequence is clearly listed with explicit checkpoints ('tests should fail', 'tests should now pass', 'verify 80%+ coverage'), but the error-recovery feedback loops are implicit rather than spelled out ('if tests still fail, debug and re-run').	2 / 3
Progressive Disclosure	Section headers give decent structure, but it is a single ~400-line monolithic file with no external references, and content that could be split (test patterns, mock recipes, CI config) is all inline.	2 / 3
	Total	9 / 12 Passed

Description

67%Weight 40%Scale 1-3

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 clearly states both capability and an explicit 'Use when' trigger, giving strong completeness, but it leads with a second-person imperative and relies on broad task triggers that dilute distinctiveness and specificity.

Suggestions

Rewrite the opening as a third-person capability statement (e.g., 'Enforces test-driven development with 80%+ coverage across unit, integration, and E2E tests') and move the trigger into a trailing 'Use when...' clause to avoid the voice penalty.

Add distinctive testing-oriented trigger terms users actually say ('write tests', 'add test coverage', 'do TDD', 'increase coverage') so it is less likely to collide with general coding skills.

Dimension	Reasoning	Score
Specificity	It lists concrete actions ('writing new features, fixing bugs, or refactoring code' and 'Enforces test-driven development with 80%+ coverage including unit, integration, and E2E tests'), but opens with the second-person imperative 'Use this skill when', which the voice guideline penalizes by -1.	2 / 3
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 an explicit trigger clause.	3 / 3
Trigger Term Quality	Natural task terms appear ('writing new features', 'fixing bugs', 'refactoring code'), but these are broad and the distinctive testing variations a user would actually say ('write tests', 'add coverage', 'do TDD') are only partially covered via 'test-driven development' and 'coverage'.	2 / 3
Distinctiveness Conflict Risk	The 'what' carves a clear TDD/coverage niche, but the 'when' triggers (features/bugs/refactoring) are broad and would overlap with a general coding skill, so it could still fire for the wrong skill.	2 / 3
	Total	9 / 12 Passed

Validation

100%

Warnings & errors only

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: ysyecust/everything-claude-code
Path: docs/zh-TW/skills/tdd-workflow/SKILL.md
Commit: a9cbecb

Reviewed: 5 days ago

Table of Contents

Discovery Implementation Validation

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.