CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

test-driven-development

Use when implementing any feature or bugfix, before writing implementation code

Quality

51%

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 ./.claude/skills/test-driven-development/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

47%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 is a harness-generated redirect stub: one comment plus one instruction pointing to an external shared skill that is not present in this environment. While maximally token-efficient, it offers no actionable TDD guidance, no workflow or validation steps, and its only reference is unreachable — as a standalone skill file it is functionally empty. Its quality depends entirely on the deployment environment providing the target file.

Suggestions

Ship the referenced content in the bundle (e.g. references/tdd-process.md) or inline the core red-green-refactor steps, since the referenced path ~/.agents/skills/test-driven-development/SKILL.md does not exist here and the skill dead-ends without it.

Add a brief inline summary of the workflow (1. write a failing test, 2. run it to confirm failure, 3. implement minimally, 4. re-run until green, 5. refactor with the suite as validation) so the skill degrades gracefully when the shared file is absent.

If the redirect pattern is intentional, add a fallback instruction (e.g. what to do if the shared skill cannot be loaded) to turn the dead-end into a recoverable path.

DimensionReasoningScore

Conciseness

The body is two lines with no padding: one generator comment and one directive. Nothing over-explains and Claude's competence is fully assumed; every token serves a purpose (the comment prevents manual edits, the line delegates). Note the leanness is largely because the body is a redirect stub, but on token efficiency alone it cannot be beat.

5 / 5

Actionability

The single directive "Load and follow the shared skill at ~/.agents/skills/test-driven-development/SKILL.md" is concrete in form (an exact path), but it is the only guidance — no steps for actually performing TDD, and the referenced path does not exist in this environment, so following it dead-ends. This matches anchor 2 (minimal concrete guidance, missing the specific steps to execute); it is above anchor 1 because a specific executable instruction is given.

2 / 5

Workflow Clarity

The only sequence present is "load, then follow" — a rough directive whose actual process steps and validation checkpoints (the heart of TDD's red-green-refactor loop) are entirely absent from the body. Anchor 2 (rough sequence, many gaps, validation absent) fits; anchor 1 would require incoherence, but the instruction itself is unambiguous, and the simple-skill exception does not apply because TDD is inherently multi-step.

2 / 5

Progressive Disclosure

The body is a pure redirect with no overview or sections, and its single reference points outside the bundle to ~/.agents/skills/test-driven-development/SKILL.md, which does not exist in this environment (verified). Navigation dead-ends: a reader cannot reach the skill's actual content. Anchor 2 (minimal structure; navigation fails) fits better than anchor 3 because there is no inlined content at all and the reference is not a real, reachable file.

2 / 5

Total

11

/

20

Passed

Description

32%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 a pure trigger clause: it says when to use the skill but never what the skill does. Its trigger scope ("any feature or bugfix") is maximally broad within coding, and it omits the most important keywords for a TDD skill — test, tests, TDD. It functions as a weak routing hint rather than a capability description.

Suggestions

State what the skill does, e.g. "Guides test-driven development: write a failing test first, implement the minimum code to pass it, then refactor. Use when implementing any feature or bugfix, before writing implementation code."

Add natural trigger keywords users would actually say: "test", "tests", "TDD", "write tests first", "fix a bug", "red-green-refactor".

Narrow the trigger scope ("any feature or bugfix" overlaps with virtually all coding skills) by tying it to the specific moment TDD applies, e.g. "Use when starting to implement a feature or bugfix and tests should drive the design."

DimensionReasoningScore

Specificity

"implementing any feature or bugfix, before writing implementation code" names the domain and timing but describes zero concrete actions (no mention of writing tests, red-green-refactor, or running test suites). It is not pure abstraction (anchor 1) because concrete development activities are named, but it never goes beyond naming the domain.

2 / 5

Completeness

The "when" is explicit ("Use when implementing any feature or bugfix, before writing implementation code") but the "what" is entirely absent — the description never states what the skill actually does. This matches anchor 2 ("only 'when' is present without 'what'", example "Use when working with documents") precisely; it cannot be 3 because no capability is stated, and per the guidelines only explicitly stated content is scored.

2 / 5

Trigger Term Quality

"implementing", "feature", and "bugfix" are phrases users naturally say, giving some relevant keywords. However common variations are missing — most notably "test", "tests", "TDD", and "fix a bug", which is a striking omission for a test-driven-development skill.

3 / 5

Distinctiveness Conflict Risk

"any feature or bugfix" would trigger on essentially every coding task, creating high overlap risk with any implementation, debugging, or refactoring skill. The timing qualifier ("before writing implementation code") confines it to the pre-implementation phase, keeping it slightly above the entirely-generic anchor 1.

2 / 5

Total

9

/

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

phatblat/dotfiles

Path

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