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 ./tests/ext_conformance/artifacts/agents-wshobson/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 project-specific terminology ('Conductor', 'phase checkpoints', 'verification protocol') without explaining what these mean or what concrete actions the skill performs. While it includes a 'Use when...' clause, the trigger terms are jargon-heavy and the capabilities described are too vague to clearly differentiate this skill or help Claude select it appropriately.
Suggestions
Add concrete actions the skill performs, e.g., 'Guides implementation through red-green-refactor TDD phases, creates phase-specific git commits, and validates test results at each checkpoint.'
Expand trigger terms with natural language variations users might say, such as 'test-driven development', 'TDD', 'red-green-refactor', 'task implementation workflow', 'phase verification'.
Briefly explain what 'Conductor' and 'verification protocol' refer to so the description is self-contained and distinguishable 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., no specific actions like 'runs tests', 'creates commits', 'validates phases'). | 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 handling phases, managing commits, and understanding a protocol without explaining what concrete outcomes the skill produces. | 2 / 3 |
Trigger Term Quality | Includes some relevant keywords like 'TDD workflow', 'git commits', 'phase checkpoints', and 'verification protocol', but these are project-specific jargon ('Conductor') rather than natural terms a user would say. 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 through a named system, but terms like 'managing git commits' and 'implementing tasks' are generic enough to overlap with general git or task management skills. | 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.
This skill provides highly actionable and well-sequenced workflow guidance with concrete commands, code examples, and clear validation checkpoints throughout the TDD lifecycle. However, it is severely bloated — much content is redundant (commit formats, checkpoint concepts, verification steps appear multiple times) and concepts Claude already understands are over-explained. The monolithic structure with no progressive disclosure makes it a poor fit for context window efficiency.
Suggestions
Reduce content by at least 50% by eliminating redundant sections (e.g., merge the two commit format explanations, consolidate verification steps that appear in both the task lifecycle and phase completion sections).
Extract detailed reference content (QA gates, deviation handling, error recovery, TDD variations, checkpoint verification details) into separate linked files, keeping only the core 11-step lifecycle and phase completion protocol in SKILL.md.
Remove explanations of concepts Claude already knows — e.g., what TDD is, what commit types mean, why tests matter, basic refactoring principles — and focus only on project-specific conventions and requirements.
Add a brief table of contents or navigation section at the top to help locate specific workflows quickly.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~400+ lines. Contains significant redundancy (git commit format explained twice, checkpoint concepts repeated across multiple sections, verification steps duplicated). 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 commit types mean, basic testing practices) are explained at length. | 1 / 3 |
Actionability | Provides fully executable commands (pytest, git, ruff, mypy), concrete code examples (Python tests, bash commands), specific markdown formats for plan updates, and copy-paste ready commit message templates. The 11-step lifecycle and phase completion protocol are highly concrete and specific. | 3 / 3 |
Workflow Clarity | The 11-step TDD lifecycle is clearly sequenced with explicit validation checkpoints (run tests at RED, GREEN, and REFACTOR stages; verify coverage at step 6; explicit WAIT for user approval at phase completion). Error recovery paths are well-defined with feedback loops (failed tests → revert to GREEN, checkpoint rejection → remediation tasks → re-request approval). | 3 / 3 |
Progressive Disclosure | Monolithic wall of text with no references to external files for detailed content. Everything is inline — the QA gates, deviation handling, error recovery, TDD variations, checkpoint verification details, and performance considerations could all be split into separate reference files. No navigation aids or links to supplementary materials. | 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
- Dicklesworthstone/pi_agent_rust
- Commit
6e3d68c
- 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.