TDD planning pipeline with multi-mode routing (plan/verify). Session discovery → context gathering (spawn_agent) → test coverage analysis (spawn_agent) → conditional conflict resolution → TDD task generation (spawn_agent) → structure validation → interactive verification. Produces IMPL_PLAN.md with Red-Green-Refactor cycles, task JSONs, TODO_LIST.md.
44
48%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.codex/skills/workflow-tdd-plan/SKILL.mdQuality
Discovery
50%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 technically detailed and specific about its pipeline stages and outputs, making it highly distinctive. However, it reads more like internal architecture documentation than a skill description—it lacks any 'Use when...' guidance and uses implementation jargon (e.g., 'spawn_agent', 'multi-mode routing') that users would never naturally say. The absence of explicit trigger conditions is a significant weakness for skill selection.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user wants to plan an implementation using test-driven development, create a TDD plan, or generate test-first task breakdowns.'
Replace internal implementation details like 'spawn_agent' and 'multi-mode routing (plan/verify)' with user-facing language describing the benefit, e.g., 'Analyzes existing code and tests to generate a structured TDD implementation plan.'
Include natural trigger terms users would say, such as 'test-driven development', 'TDD plan', 'implementation plan', 'test-first approach', 'task breakdown'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: session discovery, context gathering, test coverage analysis, conflict resolution, TDD task generation, structure validation, interactive verification. Also specifies concrete outputs: IMPL_PLAN.md, task JSONs, TODO_LIST.md. | 3 / 3 |
Completeness | Describes what it does in detail but completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. Per the rubric, a missing 'Use when...' clause should cap completeness at 2, and since the 'when' is entirely absent, this scores a 1. | 1 / 3 |
Trigger Term Quality | Contains relevant terms like 'TDD', 'test coverage', 'Red-Green-Refactor', and 'IMPL_PLAN.md', but uses heavy technical jargon ('multi-mode routing', 'spawn_agent', 'conditional conflict resolution') that users wouldn't naturally say. Missing common user phrases like 'write tests first', 'test-driven', or 'implementation plan'. | 2 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with a clear niche: TDD planning pipeline producing specific artifacts (IMPL_PLAN.md, TODO_LIST.md, task JSONs) with Red-Green-Refactor cycles. Unlikely to conflict with other skills due to its very specific domain and output format. | 3 / 3 |
Total | 9 / 12 Passed |
Implementation
47%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill has excellent workflow clarity with well-defined phases, conditional branching, validation checkpoints, and error recovery paths. However, it suffers significantly from verbosity — the TDD concepts are repeated multiple times, the ASCII diagrams are redundant with the textual descriptions, and the overall length could be cut by 40-50% without losing actionable information. Code examples are mostly concrete but contain some incomplete or syntactically invalid sections.
Suggestions
Reduce redundancy by stating TDD Red-Green-Refactor requirements once and referencing them, rather than repeating the concept in the overview, Phase 5 instructions, Phase 6 validation, Phase 7 verification, and the dedicated 'TDD Compliance Requirements' section.
Remove either the ASCII pipeline diagram or the Data Flow section — they convey nearly identical information. Keep whichever is more compact.
Fix incomplete code in Phase 4 (undefined 'conflicts' variable, missing CLI output parsing) and Phase 7 (invalid JS syntax `if (mode === 'verify' || /* auto-verify from Phase 6 */)`) to make examples truly executable.
Extract the session structure diagram, error handling table, and TDD compliance requirements into separate referenced files to improve progressive disclosure and reduce the main skill's token footprint.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is extremely verbose at ~500+ lines. It includes extensive ASCII diagrams, redundant data flow representations, and repeats TDD concepts (Red-Green-Refactor) multiple times. The session discovery logic, conflict resolution, and phase details could be significantly condensed. Claude doesn't need the Iron Law explained repeatedly or the full validation loop spelled out in such detail. | 1 / 3 |
Actionability | The code examples are fairly concrete with JavaScript snippets showing session initialization, validation logic, and agent spawning. However, several sections use pseudocode or incomplete patterns (Phase 4's conflict resolution has undefined 'conflicts' variable, Phase 7 has invalid JS syntax in the if condition), and the spawn_agent/wait_agent/close_agent APIs are used without clear documentation of their actual interface. | 2 / 3 |
Workflow Clarity | The multi-step workflow is exceptionally well-sequenced with 7 clearly numbered phases, conditional branching (Phase 4 based on conflict risk), explicit validation in Phase 6 with error recovery options (Fix and Retry, Continue, Abort), and a clear confirmation gate. The feedback loop for TDD structure validation that can re-trigger Phase 5 is well-designed. | 3 / 3 |
Progressive Disclosure | The content is monolithic — everything is in a single massive file with no references to supporting documents. The session structure diagram and data flow could be separate references. However, the internal organization with clear phase headers provides reasonable navigability within the single file. No bundle files are provided to offload content to. | 2 / 3 |
Total | 8 / 12 Passed |
Validation
72%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 8 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (754 lines); consider splitting into references/ and linking | Warning |
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 8 / 11 Passed | |
5ff5e86
Table of Contents
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.