Unified TDD workflow skill combining 6-phase TDD planning with Red-Green-Refactor task chain generation, and 4-phase TDD verification with compliance reporting. Triggers on "workflow-tdd-plan", "workflow-tdd-verify".
67
61%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./.claude/skills/workflow-tdd-plan/SKILL.mdQuality
Discovery
75%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 adequately covers both what the skill does and when to use it, with explicit trigger commands providing clear activation guidance. However, the trigger terms are command-style identifiers rather than natural language users would use, and the capability descriptions lean on TDD jargon that could be more concrete. The skill is distinctive and unlikely to conflict with others.
Suggestions
Add natural language trigger terms alongside the command triggers, e.g., 'Use when the user asks to plan tests, create a TDD workflow, verify test-driven development compliance, or mentions TDD'.
Make capabilities more concrete by specifying outputs, e.g., 'Generates phased TDD task lists, produces Red-Green-Refactor implementation steps, and creates compliance reports assessing test coverage and TDD adherence'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (TDD workflow) and mentions some actions like '6-phase TDD planning', 'Red-Green-Refactor task chain generation', '4-phase TDD verification', and 'compliance reporting', but these are somewhat jargon-heavy and not fully concrete in terms of what specific actions are performed. | 2 / 3 |
Completeness | Clearly answers both 'what' (TDD planning with 6-phase workflow, Red-Green-Refactor task chain generation, 4-phase verification with compliance reporting) and 'when' (triggers on specific commands 'workflow-tdd-plan' and 'workflow-tdd-verify'). The explicit trigger guidance is present. | 3 / 3 |
Trigger Term Quality | Includes 'workflow-tdd-plan' and 'workflow-tdd-verify' as trigger terms, plus mentions TDD, Red-Green-Refactor, and compliance reporting. However, the trigger terms are command-style identifiers rather than natural language a user would say (e.g., 'test driven development', 'write tests first', 'TDD plan'). | 2 / 3 |
Distinctiveness Conflict Risk | The description carves out a very specific niche around TDD workflow planning and verification with distinct command-based triggers. It is unlikely to conflict with other skills due to the specificity of the TDD methodology focus and the explicit trigger commands. | 3 / 3 |
Total | 10 / 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 is a comprehensive architecture document for a TDD workflow orchestrator, but it suffers from extreme verbosity and repetition — the same 6-phase sequence is described in the architecture diagram, execution flow, data flow, TodoWrite pattern, and coordinator checklist sections. While workflow clarity is excellent with proper validation gates and conditional logic, the content would benefit enormously from consolidation and moving reference material to separate files. The pseudocode JavaScript adds little value for Claude and the extensive inline examples inflate the token cost significantly.
Suggestions
Consolidate the 5+ redundant descriptions of the phase sequence (architecture, execution flow, data flow, TodoWrite, checklist) into a single authoritative flow with the checklist as the primary reference.
Move the TodoWrite state examples, error handling tables, and warning patterns into separate reference files (e.g., phases/reference/todowrite-patterns.md, phases/reference/error-handling.md) and link to them.
Remove the pseudocode JavaScript blocks (mode detection, preference collection) — these describe trivial routing logic that Claude can infer from the phase descriptions.
Cut explanatory text like 'PDF files are...' equivalents — e.g., the 'Why Order Matters' section under TDD principles explains basic TDD concepts Claude already knows.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~500+ lines with extensive repetition. The architecture diagram, data flow, TodoWrite patterns, and coordinator checklists all repeat the same phase sequence multiple times. Pseudocode JavaScript for mode detection and preference collection explains trivial concepts. The error handling tables, warning patterns, and multiple JSON state examples add significant bulk that could be condensed dramatically. | 1 / 3 |
Actionability | Provides concrete phase references (Read('phases/01-session-discovery.md')), JSON structures for TodoWrite states, and specific file outputs. However, the JavaScript code blocks are pseudocode (not executable), the actual phase logic is deferred to external files, and the skill reads more as an architecture document than executable instructions. Key details like how to actually run commands are missing from the orchestrator itself. | 2 / 3 |
Workflow Clarity | The multi-step workflow is exceptionally well-sequenced with clear phase ordering, conditional branching (Phase 4 based on conflictRisk), explicit validation checkpoints (Phase 6 TDD structure validation, Phase 7 compliance verification), error recovery tables, and a clear decision gate after Phase 6. The coordinator checklists provide step-by-step verification of data flow between phases. | 3 / 3 |
Progressive Disclosure | Good use of external phase files (phases/01-07) loaded on-demand via Read(), and the phase reference table is well-organized. However, the SKILL.md itself is monolithic — it contains massive inline content (TodoWrite state examples, full data flow diagrams, error tables, warning patterns) that could be split into reference documents. The architecture overview, data flow, and TodoWrite patterns are all inline when they could be separate files. | 2 / 3 |
Total | 8 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (528 lines); consider splitting into references/ and linking | Warning |
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
Total | 9 / 11 Passed | |
0f8e801
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.