Use this skill when implementing tasks according to Conductor's TDD workflow, handling phase checkpoints, managing git commits for tasks, or understanding the verification protocol.
71
Does it follow best practices?
If you maintain this skill, you can automatically optimize it using the tessl CLI to improve its score:
npx tessl skill review --optimize ./path/to/skillAgent success when using this skill
Validation for skill structure
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.
This description is structured entirely as trigger conditions without explaining what the skill actually does. While it mentions relevant concepts (TDD, git commits, verification), it relies on product-specific terminology that users may not naturally use and lacks concrete action descriptions. The description would benefit from leading with specific capabilities before the 'Use when' clause.
Suggestions
Add a leading statement describing concrete capabilities (e.g., 'Guides test-driven development with red-green-refactor cycles, manages phase transitions, and automates task commits.')
Include more natural trigger terms users would say, such as 'test first', 'failing test', 'red-green-refactor', 'task workflow', or 'development phases'
Clarify what 'phase checkpoints' and 'verification protocol' mean in practical terms to help Claude understand when this skill applies versus other TDD or git skills
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names domain (TDD workflow, phase checkpoints, git commits, verification protocol) and some actions (implementing, handling, managing, understanding), but these are fairly abstract rather than concrete specific actions like 'run tests', 'create commits', or 'validate phases'. | 2 / 3 |
Completeness | The description is structured as a 'Use when...' clause which addresses when to use it, but the 'what does this do' is only implied through the trigger conditions. It tells when to use it but doesn't explicitly state what capabilities or actions the skill provides. | 2 / 3 |
Trigger Term Quality | Includes some relevant terms like 'TDD', 'git commits', 'tasks', and 'verification', but relies heavily on product-specific jargon ('Conductor', 'phase checkpoints', 'verification protocol') that users may not naturally use. Missing common variations like 'test-driven', 'red-green-refactor', 'commit workflow'. | 2 / 3 |
Distinctiveness Conflict Risk | The 'Conductor' product name provides some distinctiveness, but terms like 'TDD workflow', 'git commits', and 'tasks' are generic enough to potentially overlap with other development or git-related skills. | 2 / 3 |
Total | 8 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured, highly actionable skill with excellent workflow clarity and explicit validation checkpoints. The main weakness is verbosity - the document is comprehensive but could be more concise by assuming Claude's baseline knowledge and splitting advanced content into referenced files. The quality gates and verification protocols are particularly strong.
Suggestions
Reduce verbosity by removing explanations of concepts Claude knows (e.g., what TDD is, basic git workflow) and trust Claude to fill in standard knowledge
Split advanced sections (TDD Variations, Error Recovery, Performance Considerations) into separate referenced files to improve progressive disclosure
Consolidate the 11-step lifecycle into a more compact checklist format with details available on demand
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is comprehensive but verbose in places. Some sections explain concepts Claude would know (e.g., what TDD is, basic git commands) and could be tightened. The 11-step lifecycle and extensive examples add length that could be condensed. | 2 / 3 |
Actionability | Provides fully executable code examples, specific bash commands, concrete commit message formats, and copy-paste ready templates. Each step has clear, actionable instructions with real examples. | 3 / 3 |
Workflow Clarity | Excellent multi-step workflow with explicit validation checkpoints (Step 6 coverage verification, Phase Completion Protocol with WAIT for approval). Clear feedback loops for error recovery and explicit gates before proceeding. | 3 / 3 |
Progressive Disclosure | Content is well-organized with clear headers and sections, but it's a monolithic document with no references to external files. The extensive detail (400+ lines) could benefit from splitting advanced topics like 'TDD Variations' or 'Error Recovery' into separate files. | 2 / 3 |
Total | 10 / 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 (624 lines); consider splitting into references/ and linking | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
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.