Content
22%Scale 1-3Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill fails to deliver on its stated purpose of validating Conductor project artifacts for completeness, consistency, and correctness. The content is a mix of a few concrete but shallow shell commands, generic boilerplate instructions, and useful but disconnected pattern-matching references. It lacks any actual validation workflow, success/failure criteria, or error handling that would make it functional as a validation skill.
Suggestions
Define a clear sequential validation workflow: 1) Check directory structure exists, 2) Verify required files present, 3) Validate content patterns (status markers, track IDs), 4) Report results — with explicit pass/fail criteria at each step.
Replace the generic Instructions section ('Clarify goals, constraints...') with specific validation checks, e.g., 'Verify every track in tracks.md has a corresponding directory in conductor/tracks/' and 'Check that track IDs match the pattern <type>_<name>_<YYYYMMDD>'.
Fix the 'Use this skill when' / 'Do not use this skill when' sections — they currently reference 'check if conductor directory exists' which is just the first code block's comment, not the actual skill scope (validating Conductor project artifacts).
Add concrete output examples showing what a successful validation report looks like versus a failed one, so Claude knows exactly what to produce.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is padded with generic boilerplate ('Clarify goals, constraints, and required inputs', 'Apply relevant best practices') that adds no value. The 'Use this skill when' and 'Do not use this skill when' sections redundantly repeat 'check if conductor directory exists' — which appears to be a copy-paste artifact from the title of the first code block rather than the actual skill purpose. Much of the content is filler that doesn't teach Claude anything specific. | 1 / 3 |
Actionability | The initial shell commands (ls -la conductor/, checking required files) are concrete and executable, and the pattern matching section provides specific marker formats. However, the Instructions section is entirely vague and generic ('Apply relevant best practices and validate outcomes') with no concrete validation logic, error handling, or specific checks for completeness/consistency/correctness as described in the skill's purpose. | 2 / 3 |
Workflow Clarity | There is no clear sequenced workflow for validation. The skill lists some ls commands at the top but doesn't define what to do with the results, what constitutes a pass/fail, or how to handle missing files. For a validation skill involving checking multiple artifacts for completeness and consistency, the absence of any validation logic, decision points, or error recovery is a significant gap. | 1 / 3 |
Progressive Disclosure | There is one reference to 'resources/implementation-playbook.md' for detailed examples, which is a reasonable attempt at progressive disclosure. However, no bundle files exist to support this reference, and the main content itself is poorly organized — the code block at the very top appears before any heading or context, and the sections don't flow logically from overview to detail. | 2 / 3 |
Total | 6 / 12 Passed |