workflow-patterns
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.
35
31%
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 ./plugins/conductor/skills/workflow-patterns/SKILL.mdQuality
Discovery
40%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 relies heavily on domain-specific terminology ('Conductor', 'phase checkpoints', 'verification protocol') without explaining what concrete actions the skill performs. While it includes a 'Use when...' clause, the lack of specific capabilities makes it difficult for Claude to confidently select this skill over others. The description reads more like a list of abstract concepts than actionable skill capabilities.
Suggestions
Add concrete actions the skill performs, e.g., 'Guides implementation through red-green-refactor phases, runs test suites at each checkpoint, and creates atomic git commits per phase.'
Expand trigger terms with natural user language like 'test-driven development', 'red-green-refactor', 'task workflow', 'commit after tests pass'.
Clarify what 'Conductor' is and what the 'verification protocol' entails so Claude can distinguish this from generic TDD or git skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description uses vague language like 'implementing tasks', 'handling phase checkpoints', 'managing git commits', and 'understanding the verification protocol' without listing concrete actions. It names domain concepts but doesn't describe what the skill actually does (e.g., what phases, what verification steps). | 1 / 3 |
Completeness | The description has a 'Use when...' clause addressing when to use the skill, but the 'what does this do' part is weak — it only vaguely references implementing tasks, handling checkpoints, and managing commits without explaining what concrete actions the skill performs. The 'when' is present but the 'what' is insufficiently specific. | 2 / 3 |
Trigger Term Quality | Includes some relevant keywords like 'TDD', 'git commits', 'phase checkpoints', and 'verification protocol', but these are somewhat jargon-heavy and specific to the 'Conductor' system. A user might say 'TDD' or 'git commit' naturally, but terms like 'phase checkpoints' and 'verification protocol' are less natural. | 2 / 3 |
Distinctiveness Conflict Risk | The mention of 'Conductor's TDD workflow' provides some distinctiveness by naming a specific system, but terms like 'managing git commits' and 'implementing tasks' are generic enough to overlap with other development or git-related skills. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
22%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is essentially a placeholder that names concepts (TDD workflow, phase checkpoints, verification protocol) without actually teaching any of them. It lacks executable examples, concrete workflow steps, and validation checkpoints — the very things it claims to cover. The best practices list is generic advice that Claude already knows, and the real content is deferred entirely to a referenced file that may or may not exist.
Suggestions
Add a concrete, step-by-step workflow showing the TDD red-green-refactor cycle with actual commands (e.g., how to run tests, what a failing test looks like, how to commit with git notes).
Include at least one worked example showing a complete phase checkpoint: writing a failing test, making it pass, committing, and updating plan.md with specific format/content.
Add explicit validation checkpoints in the workflow (e.g., 'Run `pytest --cov` and verify coverage >= target before proceeding to next phase').
Remove or significantly trim the best practices list — most items are generic software engineering principles Claude already knows. Keep only project-specific conventions.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The best practices list is somewhat verbose and contains generic software engineering advice Claude already knows (e.g., 'small commits', 'clean state', 'fast feedback'). The 'When to Use This Skill' section is also somewhat redundant with the opening description. | 2 / 3 |
Actionability | The skill provides no concrete code, commands, or executable examples. It is entirely abstract guidance — 'write failing tests first', 'update plan.md' — without showing what any of these steps actually look like, what commands to run, or what format to use. | 1 / 3 |
Workflow Clarity | Despite claiming to guide a TDD workflow with phase checkpoints and verification protocols, there is no actual workflow sequence, no numbered steps showing the process, no validation checkpoints, and no feedback loops. The content describes concepts without sequencing them. | 1 / 3 |
Progressive Disclosure | There is a reference to 'references/details.md' for detailed patterns, which is good progressive disclosure in principle. However, no bundle files were provided to verify this reference exists, and the SKILL.md itself contains almost no substantive content to serve as a useful overview — it's too thin to function as a proper entry point. | 2 / 3 |
Total | 6 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
- Repository
- wshobson/agents
- Commit
cf6059d
- 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.