CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

test-driven-development

Implements a feature or bug fix test-first - write one failing test, watch it fail, write the minimal code to pass, then refactor with tests green. This is the implementation stage inside the delivery-flow workflow, entered by requests like "implement this feature", "fix this bug", "write the code for this", or "add the tests and implement it" once delivery-flow is driving the change. Do not activate directly for a standalone request that has not gone through delivery-flow first.

75

Quality

94%

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

The canonical home for this skill is test-driven-development in tesslio/tessl-eval-demo

SKILL.md
Quality
Evals
Security

Quality

Content

92%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.

An exemplary lean skill body: a crisp numbered workflow with genuine validation checkpoints, a failure feedback loop, and a done-checklist, plus a clearly signaled reference that exists in the bundle. The only minor weakness is the generic "Run the project's test command" phrasing.

Suggestions

Make the test-run step more concrete, e.g. "Run the project's test command (e.g. npm test / pytest) — discover it if unknown" to reduce the one generic instruction.

DimensionReasoningScore

Conciseness

"Write the test first. Watch it fail. Write the minimal code to pass. Refactor with the tests green." — every line is directive with zero re-teaching of concepts Claude already knows. Not 4: there is no over-explanation anywhere to trim; even the rationale lines ("If it passes, it tests nothing new") are actionable rules, not padding.

5 / 5

Actionability

The cycle gives concrete, specific guidance ("Write one test for one behavior", "The test must fail because the behavior is missing, not because of a typo or a missing import"), and test-writing detail is correctly delegated to the reference. Not 5: "Run the project's test command" is generic rather than a specific command or example, leaving minor gaps in executable specificity.

4 / 5

Workflow Clarity

The Red/Green/Refactor cycle is a clearly numbered sequence with explicit validation checkpoints ("Watch it fail", "Watch it pass", "Run the full suite"), a failure feedback loop ("If it passes, it tests nothing new: change the test"), and a final "Before you say it is done" checklist. This matches the top anchor including error-recovery feedback.

5 / 5

Progressive Disclosure

A short, well-sectioned body with a single one-level-deep reference — "When writing or changing a test, read [references/writing-good-tests.md]" — which points to a real, relevant file in the bundle. Content is appropriately split (process inline, test-writing craft in the reference); nothing is inlined that belongs elsewhere.

5 / 5

Total

19

/

20

Passed

Description

92%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: concrete multi-step capabilities, explicit trigger phrases, and unusually clear activation boundaries including a negative guard clause. It uses third person and stays concise while remaining comprehensive.

Suggestions

Add common trigger synonyms such as "TDD" or "write the tests first" to the trigger phrase list for fuller coverage.

DimensionReasoningScore

Specificity

"Implements a feature or bug fix test-first - write one failing test, watch it fail, write the minimal code to pass, then refactor with tests green" lists multiple concrete actions covering the entire TDD cycle comprehensively. Not 4: there are no meaningful gaps in coverage of the skill's actions.

5 / 5

Completeness

Explicitly answers what (test-first cycle enumerated step by step) and when ("entered by requests like... once delivery-flow is driving the change" plus "Do not activate directly for a standalone request"). Both what and when are stated with concrete trigger phrases, matching the top anchor.

5 / 5

Trigger Term Quality

Quoted trigger phrases like "implement this feature", "fix this bug", "write the code for this", or "add the tests and implement it" are natural user requests with good variety. Not 5: a few natural terms users would say are missing (e.g. "TDD", "write the tests", "make this change").

4 / 5

Distinctiveness Conflict Risk

"This is the implementation stage inside the delivery-flow workflow" and "Do not activate directly for a standalone request that has not gone through delivery-flow first" give it a clear niche with explicit gating, minimizing conflict with other skills. Not 4: the do-not-activate guard removes even minor overlap risk.

5 / 5

Total

19

/

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

tesslio/tessl-eval-demo

Path

06-regression/versions/old-description/sdlc-implementation/skills/test-driven-development/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.