workflow-tdd-plan-plan
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".
53
61%
Does it follow best practices?
Impact
—
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 effectively communicates a specialized TDD workflow skill with clear trigger commands and a distinct niche. Its main weakness is relying on command-style triggers rather than natural language terms users might use, and the capability descriptions lean toward abstract phase names rather than concrete actions. Adding natural language trigger terms and more specific action descriptions would improve discoverability.
Suggestions
Add natural language trigger terms users might say, such as 'test-driven development', 'TDD', 'write tests first', 'red green refactor cycle', or 'test planning'.
Replace abstract phase descriptions with concrete actions, e.g., 'Generates ordered task chains for writing failing tests, implementing code, and refactoring; produces TDD compliance reports with pass/fail metrics'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description 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'. However, these are somewhat abstract phases rather than concrete user-facing actions like 'generates test files' or 'validates test coverage'. | 2 / 3 |
Completeness | The description answers both 'what' (unified TDD workflow combining planning with task chain generation and 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 | It includes specific command triggers ('workflow-tdd-plan', 'workflow-tdd-verify') which are useful for exact matching, but lacks natural language terms users might say like 'test-driven development', 'write tests first', 'TDD cycle', 'red green refactor', or 'test planning'. The triggers feel like slash commands rather than natural keywords. | 2 / 3 |
Distinctiveness Conflict Risk | The description is highly specific to a unified TDD workflow with distinct command triggers, making it unlikely to conflict with other skills. The combination of TDD planning, Red-Green-Refactor chains, and verification/compliance reporting carves out a clear niche. | 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 has excellent workflow clarity with well-defined phases, conditional logic, validation gates, and error handling. However, it is severely over-engineered and verbose — the same information is repeated across architecture diagrams, execution flows, data flows, and checklists. The content explains orchestration patterns and state management concepts that Claude already understands, and includes extensive pseudocode JSON examples for trivial state transitions that add little value.
Suggestions
Consolidate the redundant sections: merge the architecture overview, execution flow, data flow, and coordinator checklist into a single concise workflow description — currently the phase sequence is described 4+ times.
Remove the verbose TodoWrite JSON state examples (sections showing Phase 3 attached/collapsed states) — Claude understands state machine patterns; a one-line description of the attach/execute/collapse pattern suffices.
Move the error handling tables, TDD warning patterns, and TDD compliance checkpoint tables into a separate reference file (e.g., phases/error-reference.md) to keep the orchestrator SKILL.md lean.
Remove explanatory content like 'Why Order Matters' and 'Red Flags - STOP and Reassess' — these explain basic TDD philosophy that Claude already knows; keep only the structural enforcement rules.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~500+ lines. Massive amounts of redundancy: the data flow is described at least 3 times (architecture diagram, execution flow, data flow, coordinator checklist). Explains orchestration concepts Claude already understands. The TodoWrite pattern section alone has extensive JSON examples showing trivial state transitions. Much content could be compressed to 1/4 the size. | 1 / 3 |
Actionability | Provides concrete phase references, file paths, and structured data flow, but the JavaScript code blocks are pseudocode (not executable), and the actual execution logic is deferred to phase files that aren't provided. The skill tells Claude what to coordinate but many specifics (actual commands, tool invocations) are abstract or delegated. | 2 / 3 |
Workflow Clarity | The multi-step workflow is clearly sequenced with explicit phase ordering, conditional branching (Phase 4 based on conflictRisk), validation checkpoints (Phase 6 TDD structure validation), error handling with retry logic, and a confirmation gate before proceeding. The coordinator checklists provide explicit step-by-step verification. | 3 / 3 |
Progressive Disclosure | References 7 phase files via Read() pattern which is good progressive disclosure in principle, but no bundle files are provided to verify they exist. The SKILL.md itself is monolithic — it inlines enormous amounts of detail (TodoWrite state examples, error tables, data flow diagrams) that should live in the phase files or separate references. The architecture overview, execution flow, data flow, and coordinator checklist all repeat the same information. | 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 | |
- Repository
- catlog22/Claude-Code-Workflow
- Commit
5ff5e86
- 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.