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.
64
47%
Does it follow best practices?
Impact
100%
1.75xAverage score across 3 eval scenarios
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 trigger terms are tool-specific jargon rather than natural user language, and the capabilities described are too vague to clearly differentiate this skill from general TDD or git workflow skills.
Suggestions
Add specific concrete actions the skill performs, e.g., 'Guides through red-green-refactor TDD phases, runs test suites, creates phase-specific git commits, and verifies phase completion before advancing.'
Include natural trigger terms users would say, such as 'test-driven development', 'red-green-refactor', 'task workflow', 'run tests before committing'.
Briefly explain what 'Conductor' is and what the 'verification protocol' entails so the description is self-contained and not dependent on prior knowledge.
| 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., run tests, create commits, verify phase completion). | 1 / 3 |
Completeness | The description has a 'Use when...' clause that addresses when to use the skill, but the 'what does this do' part is weak — it only vaguely references handling checkpoints and managing commits without explaining the concrete capabilities. The 'when' is present but the 'what' is insufficiently detailed. | 2 / 3 |
Trigger Term Quality | Includes some relevant keywords like 'TDD workflow', 'git commits', 'phase checkpoints', and 'verification protocol', but these are fairly specific to the tool ('Conductor') and may not match natural user language. Missing common variations like 'test-driven development', 'red-green-refactor', 'task phases'. | 2 / 3 |
Distinctiveness Conflict Risk | The mention of 'Conductor's TDD workflow' provides some distinctiveness, but terms like 'managing git commits' and 'implementing tasks' are generic enough to overlap with general git or task management skills. The proprietary tool name helps but the broad phrasing creates some conflict risk. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
55%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill provides highly actionable, well-sequenced workflow guidance with strong validation checkpoints and error recovery paths. However, it is severely bloated—easily 3-4x longer than necessary—with extensive redundancy (commit formats, checkpoint concepts, git notes all repeated), unnecessary explanations of concepts Claude already knows, and no progressive disclosure structure despite being a very long document.
Suggestions
Reduce content by 50-60%: eliminate redundant sections (commit message format appears twice, checkpoint concepts repeated in 3+ places), remove explanations of basic concepts (what TDD is, what git notes do, why checkpoints matter).
Split into multiple files: keep the 11-step lifecycle and phase completion protocol in SKILL.md, move TDD variations, error recovery, deviation handling, and verification details into separate referenced files.
Add a table of contents or navigation section at the top to help locate specific workflows in this lengthy document.
Consolidate the 'Best Practices' section—most items are already stated as instructions in the workflow steps above, making them pure redundancy.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~400+ lines. Contains significant redundancy (commit message format explained twice, checkpoint concepts repeated across multiple sections, git notes explained multiple times). Sections like 'Why Checkpoints Matter', 'Performance Considerations', and 'Best Practices' largely restate what was already covered. Many concepts Claude already knows (what TDD is, what git notes are, basic testing patterns) are over-explained. | 1 / 3 |
Actionability | Provides fully executable commands (pytest, git, ruff, mypy), concrete code examples (Python tests, bash commands), specific commit message formats, and exact markdown syntax for plan updates. The 11-step lifecycle and phase completion protocol are copy-paste ready. | 3 / 3 |
Workflow Clarity | The 11-step TDD lifecycle is clearly sequenced with explicit validation checkpoints (run tests at RED, GREEN, REFACTOR stages; coverage check at step 6; explicit WAIT for user approval at phase completion). Error recovery paths are defined (failed tests, checkpoint rejection, blocked dependencies). Feedback loops are present throughout. | 3 / 3 |
Progressive Disclosure | Monolithic wall of text with no references to external files. Everything is inline in one massive document. Content like TDD variations by task type, manual verification guidance, deviation documentation, and error recovery could easily be split into separate reference files. No navigation aids or table of contents for this lengthy document. | 1 / 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 (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 | |
- Repository
- wshobson/agents
- Commit
70444e5
- 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.