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.

58

Quality

73%

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 ./.agents/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 body delivers a well-sequenced TDD workflow with concrete, mostly executable guidance, and the Step 0 runner-detection material is genuinely non-obvious and valuable. It is significantly undermined by verbosity — large sections teach generic testing knowledge Claude already has — and by a monolithic structure that inlines reference-level content instead of splitting it into bundle files.

Suggestions

Cut or compress sections that restate standard knowledge ('Best Practices', 'Common Testing Mistakes', 'Success Metrics', the test-type taxonomy) and keep only project-specific guidance such as the runner-detection matrix and coverage thresholds.

Move the mock patterns, E2E/Playwright patterns, and per-framework test examples into references/ files linked from a short overview section, and ship or remove the referenced scripts/setup-package-manager.js so all referenced paths resolve.

Add explicit error-recovery loops at each gate (what to do when RED tests unexpectedly pass, GREEN tests fail, or coverage is below 80%) to close the workflow's validation gaps.

DimensionReasoningScore

Conciseness

Several sections restate knowledge Claude already has — the unit/integration/E2E taxonomy, the 10-item 'Best Practices' list (Arrange-Act-Assert, one assert per test), 'Common Testing Mistakes', 'Success Metrics', and long generic Button/Playwright/mock examples — making the body noticeably padded beyond the genuinely valuable Step 0 runner-detection content.

2 / 5

Actionability

Guidance is mostly executable: a concrete runner command matrix, real bun test commands, working Jest/Playwright snippets, coverage config, and a file-layout tree. Minor gaps remain where examples are skeletons ("// Test implementation", "// Implementation here", "// Test error handling").

4 / 5

Workflow Clarity

Steps 0–7 are clearly sequenced with explicit RED ("Tests should fail"), GREEN ("Tests should now pass"), and coverage gates. However, no error-recovery guidance exists for when a gate fails unexpectedly (RED tests pass, GREEN fails, or coverage falls short of 80%), a minor validation gap that keeps it below anchor 5.

4 / 5

Progressive Disclosure

The bundle is a single monolithic file with no references/ or scripts/ directory, yet it invokes scripts/setup-package-manager.js (not present in the bundle) and inlines ~200 lines of reference-style material (mock patterns, E2E patterns, common mistakes) that belong in separate files. Good section headers keep it above anchor 2.

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.

A strong description that clearly states what the skill does and when to use it, with a quantified coverage standard and natural trigger phrases. Its main weaknesses are trigger breadth that overlaps almost all coding tasks and the absence of testing-specific trigger terms.

Suggestions

Add testing-domain trigger phrases (e.g. 'write tests', 'test coverage', 'unit/integration/E2E tests') so the skill also surfaces when users explicitly ask for testing rather than only for feature/bug/refactor work.

Narrow or qualify the activation triggers (e.g. tie them to projects with coverage requirements) to reduce conflict risk with general coding and code-review skills.

DimensionReasoningScore

Specificity

"Enforces test-driven development with 80%+ coverage including unit, integration, and E2E tests" names concrete capabilities with a quantified threshold, but it is a single policy statement rather than a comprehensive list of actions (no RED/GREEN cycle, test-first ordering, or runner guidance).

4 / 5

Completeness

It explicitly answers both parts: the what ("Enforces test-driven development with 80%+ coverage including unit, integration, and E2E tests") and the when ("Use this skill when writing new features, fixing bugs, or refactoring code") with concrete trigger phrases.

5 / 5

Trigger Term Quality

"writing new features, fixing bugs, or refactoring code" are natural phrases users would say, but testing-side triggers such as "write tests", "test coverage", "unit tests", or "TDD" are missing, leaving a few natural terms uncovered.

4 / 5

Distinctiveness Conflict Risk

The triggers "writing new features, fixing bugs, or refactoring code" fire on nearly all development work, creating real overlap risk with general coding skills, though the TDD/coverage-enforcement purpose carves out a recognizable niche.

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

referenced_paths_exist

Referenced path issues: 1 missing

Warning

Total

15

/

16

Passed

Repository

ysyecust/everything-claude-code

Path

.agents/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.