Validates Conductor project artifacts for completeness, consistency, and correctness. Use after setup, when diagnosing issues, or before implementation to verify project context.
44
44%
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 ./skills/conductor-validator/SKILL.mdQuality
Discovery
67%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 has a solid structure with both 'what' and 'when' clauses clearly stated, which is its strongest aspect. However, it lacks specificity about what concrete validation actions are performed and what 'Conductor project artifacts' actually are. The trigger terms are adequate but could be more natural and varied to help Claude distinguish this skill from general validation or debugging skills.
Suggestions
Add specific concrete actions being validated, e.g., 'Checks configuration files, verifies dependency declarations, validates schema definitions' to improve specificity.
Include more natural trigger terms users might say, such as 'check project setup', 'verify configuration', 'troubleshoot Conductor', or 'project health check'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain ('Conductor project artifacts') and some actions ('validates for completeness, consistency, and correctness'), but doesn't list specific concrete actions like checking config files, verifying dependencies, or validating schemas. | 2 / 3 |
Completeness | Clearly answers both what ('Validates Conductor project artifacts for completeness, consistency, and correctness') and when ('Use after setup, when diagnosing issues, or before implementation to verify project context') with explicit trigger guidance. | 3 / 3 |
Trigger Term Quality | Includes some relevant terms like 'validate', 'diagnosing issues', 'project context', and 'setup', but relies on domain-specific jargon ('Conductor project artifacts') that users may not naturally say. Missing common variations like 'check', 'verify config', 'troubleshoot'. | 2 / 3 |
Distinctiveness Conflict Risk | The 'Conductor project' scoping helps narrow the domain, but 'validates artifacts' and 'diagnosing issues' are fairly broad and could overlap with general linting, testing, or debugging skills. The term 'project context' is vague enough to potentially conflict. | 2 / 3 |
Total | 9 / 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 fails to deliver on its stated purpose of validating Conductor project artifacts for completeness, consistency, and correctness. It provides a few concrete shell commands for listing files but lacks any actual validation logic, success/failure criteria, or structured workflow. Much of the content is generic boilerplate that doesn't add value, and the 'Use this skill when' sections appear to be template artifacts with incorrect scope descriptions.
Suggestions
Define explicit validation checks with pass/fail criteria (e.g., 'Verify index.md contains a project name header', 'Check that every track in tracks.md has a corresponding directory under conductor/tracks/').
Add a sequenced validation workflow with numbered steps, expected outputs, and what to do when validation fails for each check.
Remove all generic boilerplate (the vague Instructions bullets, the templated 'Use/Do not use' sections) and replace with specific, actionable validation guidance.
Add a summary output format showing validation results (e.g., a checklist of what passed and what failed) so the skill produces a clear, structured report.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill 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 repeat the same phrase ('check if conductor directory exists') multiple times, which appears to be a template error. The limitations section is entirely generic. | 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 abstract ('Apply relevant best practices and validate outcomes'), and there's no actual validation logic—just listing files without checking their content or structure for correctness/consistency. | 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 completeness, consistency, and correctness, the absence of any validation checkpoints or error recovery steps is a significant gap. | 1 / 3 |
Progressive Disclosure | There is one reference to 'resources/implementation-playbook.md' for detailed examples, which is a reasonable pointer. However, no bundle files exist to support this reference, and the skill itself is somewhat monolithic with boilerplate sections that could be trimmed rather than split out. | 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 | |
f5dc9e3
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.