tdd

TDD deprecated shim

Quality

42%

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/tdd/SKILL.md

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 content is a punchy, well-sequenced TDD discipline guide with strong validation checkpoints and error-recovery rules. Its main weaknesses are non-executable placeholder command blocks, mild redundancy between the Iron Law and enforcement table, and an all-inline structure that foregoes progressive disclosure.

Suggestions

Replace the empty Commands bash blocks with a concrete example or remove them, since comment-only placeholders are not executable.

Consolidate the Iron Law and Enforcement Rules table to remove redundancy and recover token budget.

Consider moving the External Model Consultation protocol to a separate reference file to enable one-level-deep progressive disclosure.

Dimension	Reasoning	Score
Conciseness	The body is mostly lean and directive ("NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST", "Write code before test? DELETE IT.") without over-explaining TDD, but the Iron Law and Enforcement Rules table restate the same rules and the Commands section uses empty placeholder bash blocks, so it could be tightened — score 2 rather than the fully lean score 3.	2 / 3
Actionability	The Red-Green-Refactor steps and Enforcement Rules table give concrete directives, but the Commands section's bash blocks contain only comments ("# Run the project's test command") rather than executable commands, matching score 2's "pseudocode instead of executable code; missing key details" rather than the copy-paste-ready score 3.	2 / 3
Workflow Clarity	The cycle is explicitly sequenced (RED → GREEN → REFACTOR → REPEAT) with validation checkpoints ("MUST FAIL", "MUST PASS", "Run tests after EVERY change") and the Enforcement Rules table provides error-recovery feedback loops, matching score 3's "Clear sequence with explicit validation steps; feedback loops for error recovery".	3 / 3
Progressive Disclosure	The body is well-organized into clear headed sections with no broken or nested references, but at ~100 lines everything is inline with no split-out material (e.g. the External Model Consultation protocol could be a separate reference), fitting score 2's "content that should be separate is inline" rather than the split, one-level-deep score 3.	2 / 3
	Total	9 / 12 Passed

Description

22%

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 three-word deprecation label rather than a capability statement: it names the TDD niche but states no actions and gives no usage triggers. It is too thin to effectively route or distinguish the skill.

Suggestions

Add concrete actions, e.g. "Routes test-first discipline requests to the active implementation workflow and verifies with the project test suite."

Add an explicit trigger clause such as "Use when a request mentions TDD, test-driven development, or test-first workflow."

Clarify the deprecation status in the description so routing avoids this shim, e.g. "Deprecated: do not route; prefer the active implementation workflow."

Dimension	Reasoning	Score
Specificity	The description "TDD deprecated shim" names a domain but describes no concrete actions — there are no verbs listing what the skill does, matching the score-1 anchor "Vague or no actions; abstract language" rather than score 2 which requires naming some actions.	1 / 3
Completeness	It weakly conveys a "what" (a deprecated TDD shim) but entirely omits any "when to use" trigger, and the what itself is minimal — this matches score 1's "Missing what OR when, or both very weak"; it cannot reach score 2's "Has what" bar because the what is too thin.	1 / 3
Trigger Term Quality	"TDD" is a natural keyword developers actually say, but the description offers no common variations (e.g. "test-driven development", "test-first", "tests"), fitting score 2's "Some relevant keywords but missing common variations" rather than the full coverage of score 3.	2 / 3
Distinctiveness Conflict Risk	"TDD" carves a recognizable niche but the terse phrasing and absence of triggers mean it could still overlap with other TDD-related skills, fitting score 2's "Somewhat specific but could still overlap" rather than the clearly-distinct score 3.	2 / 3
	Total	6 / 12 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
description_field	'description' is very short (19 chars), consider making it more detailed	Warning

	Total	15 / 16 Passed

Repository: Yeachan-Heo/oh-my-codex
Path: skills/tdd/SKILL.md
Commit: 435d4a9

Reviewed: 2 days 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.