test-driven-development

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

Quality

58%

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

Quality

Content

77%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 crisp, fully actionable TDD workflow with excellent validation checkpoints and feedback loops, and its code examples are copy-paste ready. Its weaknesses are redundancy across the enforcement sections and a dangling reference to a missing bundle file (writing-good-tests.md).

Suggestions

Fix the broken reference: either add references/writing-good-tests.md with the four listed rules, or inline those rules and remove the link.

Trim redundancy — 'The Iron Law', 'Common Rationalizations', and 'Red Flags' repeat the same enforcement message; consolidate into one table with short 'Reality' cells.

Replace the graphviz dot cycle diagram with a one-line textual cycle (RED → verify fail → GREEN → verify pass → REFACTOR) — it duplicates the section headings at notable token cost.

Dimension	Reasoning	Score
Conciseness	The body is mostly lean imperative guidance, but pads several sections: 'Violating the letter of the rules is violating the spirit of the rules', a graphviz dot block of questionable value, and multi-sentence 'Reality' cells in the rationalizations table. 'Common Rationalizations', 'Red Flags', and 'The Iron Law' also repeat the same enforcement message three ways, which is more than the 'minor' trimming of anchor 4.	3 / 5
Actionability	Guidance is fully executable: copy-paste-ready TypeScript test and implementation code with Good/Bad contrasts, concrete commands ('npm test path/to/test.test.ts'), and a complete worked bug-fix example from RED through REFACTOR. Specific examples cover the common cases.	5 / 5
Workflow Clarity	RED → Verify RED → GREEN → Verify GREEN → REFACTOR is explicitly sequenced, both verify steps are marked MANDATORY with explicit failure checks, and error-recovery feedback loops are given ('Test fails? Fix code, not test'; 'Test errors? Fix error, re-run'). A verification checklist closes the loop — a direct match for anchor 5.	5 / 5
Progressive Disclosure	Sections are well organized and there is exactly one clearly-signaled external reference ('read [writing-good-tests.md](writing-good-tests.md)' with a bullet summary of its contents), but that file does not exist — no references/, scripts/, or assets/ directories are present, so navigation dead-ends. Good structure with a broken one-level reference fits anchor 3 rather than 4.	3 / 5
	Total	16 / 20 Passed

Description

40%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 has a clear, natural trigger clause but completely omits what the skill does — no capability is stated, and it never mentions testing or TDD. It also conflicts broadly by claiming all feature/bugfix work. Adding a concrete 'what' (e.g. enforcing the red-green-refactor cycle) and test-related trigger terms would fix most weaknesses.

Suggestions

State the 'what' explicitly, e.g. 'Enforce the red-green-refactor test-driven development cycle: write a failing test, verify it fails, write minimal code, refactor.'

Add natural trigger terms users would say for this skill: 'test first', 'write tests', 'TDD', 'unit test', 'refactoring'.

Narrow or clarify the trigger scope ('any feature or bugfix' overlaps virtually every coding skill) — e.g. name the lifecycle moment: 'before writing implementation code for any feature or bugfix, in any language or test framework'.

Dimension	Reasoning	Score
Specificity	The description only says 'Use when implementing any feature or bugfix, before writing implementation code' — it names the domain but lists no concrete actions or capabilities (it never states what the skill actually does, e.g. enforce a test-first cycle). This matches anchor 2, not anchor 3, because no 1-2 concrete actions are given.	2 / 5
Completeness	An explicit 'Use when...' trigger is present, but the 'what' is entirely missing: the description never says what the skill does. This matches anchor 2 ('only when is present without what'); it cannot be 3 because anchor 3 requires a clear 'what'.	2 / 5
Trigger Term Quality	Natural phrases like 'implementing', 'feature', 'bugfix', and 'before writing implementation code' are terms users actually say. It falls short of anchor 5 because common variations for this skill — 'test', 'TDD', 'write tests first', 'refactor' — are absent.	4 / 5
Distinctiveness Conflict Risk	'Any feature or bugfix' would fire on virtually every coding task, creating high overlap risk with all implementation-oriented skills. It is scoped to code work (not anchor 1's total genericity), so anchor 2 is the best fit.	2 / 5
	Total	10 / 20 Passed

Validation

93%

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 — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
relative_links	Relative link issues: 1 missing	Warning

	Total	15 / 16 Passed

Repository: obra/superpowers
Path: skills/test-driven-development/SKILL.md
Commit: 8ca22db

Reviewed: 1 day 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.