CtrlK
BlogDocsLog inGet started
Tessl Logo

test-driven-development

Use when implementing any feature or bugfix, before writing implementation code - write the test first, watch it fail, write minimal code to pass; ensures tests actually verify behavior by requiring failure first

56

Quality

64%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Fix and improve this skill with Tessl

tessl review fix ./plugins/tdd/skills/test-driven-development/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

62%

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

The skill provides excellent actionable guidance with clear workflows, executable code examples, and explicit verification checkpoints. However, it is severely bloated with repetitive motivational content—the same arguments against skipping TDD are made in at least 4 different sections (Why Order Matters, Common Rationalizations table, Red Flags list, and TDD Prevents These Anti-Patterns). Claude doesn't need persuasion; it needs instructions. The anti-patterns section, while valuable, should be a separate file to improve progressive disclosure.

Suggestions

Remove the 'Why Order Matters' section and 'Common Rationalizations' table entirely—they repeat the same points and Claude doesn't need motivational arguments, just rules to follow.

Extract the 'Testing Anti-Patterns' section into a separate ANTI_PATTERNS.md file and reference it from the main SKILL.md to improve progressive disclosure and reduce document length.

Consolidate the 'Red Flags' list—many items are restatements of the same principle ('Code before test,' 'Test after implementation,' 'Tests added later,' 'I already manually tested it' all mean the same thing).

Remove the dot graph definition—Claude cannot render Graphviz diagrams, and the Red-Green-Refactor cycle is already clearly explained in the subsequent sections.

DimensionReasoningScore

Conciseness

Extremely verbose and repetitive. The same points about 'delete code and start over,' 'tests after prove nothing,' and 'sunk cost fallacy' are restated across multiple sections (Why Order Matters, Common Rationalizations, Red Flags). The anti-patterns section repeats TDD principles already covered. The motivational/philosophical content (explaining why TDD matters, countering rationalizations) is extensive and largely unnecessary for Claude, who doesn't need persuasion—just instructions.

1 / 3

Actionability

Provides fully executable TypeScript code examples for both good and bad patterns, concrete bash commands for verification steps, and specific examples for bug fixes. The code is copy-paste ready and demonstrates real behavior testing patterns clearly.

3 / 3

Workflow Clarity

The Red-Green-Refactor cycle is clearly sequenced with explicit verification checkpoints at each stage (Verify RED, Verify GREEN). Includes feedback loops (test errors → fix → re-run, test passes unexpectedly → fix test). The verification checklist at the end provides a comprehensive gate before marking work complete. The bug fix example walks through the complete cycle.

3 / 3

Progressive Disclosure

The content is a monolithic document combining two substantial topics (TDD methodology and Testing Anti-Patterns) in a single file. The anti-patterns section could be a separate referenced file. No bundle files exist to offload detailed content. The document is well-structured with clear headers but is overly long for a single SKILL.md.

2 / 3

Total

9

/

12

Passed

Description

67%

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 effectively communicates the TDD workflow and includes an explicit 'Use when' clause, which is its strongest aspect. However, it lacks specific natural trigger terms like 'TDD' or 'test-driven development' that users would commonly use, and its trigger condition ('any feature or bugfix') is overly broad, creating potential conflicts with other coding-related skills.

Suggestions

Add explicit trigger terms users would naturally say: 'TDD', 'test-driven development', 'red-green-refactor', 'write tests first', 'unit test'

Narrow the 'Use when' clause to reduce conflict risk - instead of 'any feature or bugfix', specify it should be used when the user explicitly requests TDD methodology or test-first approaches

DimensionReasoningScore

Specificity

The description names the domain (TDD/test-first development) and describes the core workflow (write test first, watch it fail, write minimal code to pass), but doesn't list multiple specific concrete actions beyond the basic TDD cycle. It's more of a process description than a list of concrete capabilities.

2 / 3

Completeness

The description explicitly answers both 'what' (write the test first, watch it fail, write minimal code to pass, ensures tests verify behavior) and 'when' ('Use when implementing any feature or bugfix, before writing implementation code'). The 'Use when...' clause is present and explicit.

3 / 3

Trigger Term Quality

It includes some relevant terms like 'test', 'feature', 'bugfix', 'implementation code', but misses common natural trigger terms users would say such as 'TDD', 'test-driven development', 'red-green-refactor', 'unit test', or 'write tests'. The phrase 'implementing any feature or bugfix' is somewhat natural but broad.

2 / 3

Distinctiveness Conflict Risk

While the TDD methodology is a distinct niche, the trigger 'implementing any feature or bugfix' is extremely broad and could conflict with general coding skills, implementation skills, or testing skills. It would potentially trigger for nearly any coding task, reducing distinctiveness.

2 / 3

Total

9

/

12

Passed

Validation

90%

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

Validation10 / 11 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (699 lines); consider splitting into references/ and linking

Warning

Total

10

/

11

Passed

Repository
NeoLabHQ/context-engineering-kit
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.