CtrlK
BlogDocsLog inGet started
Tessl Logo

conductor-validator

Validates Conductor project artifacts for completeness, consistency, and correctness. Use after setup, when diagnosing issues, or before implementation to verify project context.

44

Quality

44%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./skills/conductor-validator/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

22%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

This skill claims to validate Conductor project artifacts but fails to provide a coherent validation workflow with pass/fail criteria, error handling, or recovery steps. The content is a mix of concrete but incomplete shell commands and generic boilerplate instructions that don't teach Claude anything useful. The pattern matching section is the strongest part but is disconnected from any validation logic.

Suggestions

Define a clear sequential validation workflow: check directory exists → verify required files → validate file contents → report results with pass/fail status for each check.

Replace generic Instructions bullets ('Apply relevant best practices') with specific validation checks, e.g., 'Verify tracks.md contains at least one track entry matching the pattern <type>_<name>_<YYYYMMDD>'.

Add explicit error handling: what should Claude do when a required file is missing or a pattern doesn't match? Include concrete remediation steps or error messages.

Remove the boilerplate 'Use this skill when / Do not use this skill when' sections or make them specific to actual validation scenarios rather than repeating 'check if conductor directory exists'.

DimensionReasoningScore

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 repeat the same phrase ('check if conductor directory exists') multiple times without adding clarity. The limitations section is entirely generic filler.

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 ('Apply relevant best practices and validate outcomes') with no concrete validation logic, error handling, or what to do when files are missing.

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 results, how to handle missing files, or what constitutes a passing vs failing validation. For a validation skill, the absence of any pass/fail criteria or error recovery steps is a critical gap.

1 / 3

Progressive Disclosure

There is one reference to 'resources/implementation-playbook.md' for detailed examples, which is appropriate. However, no bundle files exist to support this reference, and the main content mixes overview-level commands with pattern-matching details that could be better organized.

2 / 3

Total

6

/

12

Passed

Description

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 main strength. However, it lacks specificity in the concrete actions performed (what exactly is being validated?) and relies on somewhat generic validation language that could overlap with other skills. The trigger terms could be more natural and varied.

Suggestions

Add specific concrete actions being performed, e.g., 'Checks configuration files, verifies dependency declarations, validates schema definitions in Conductor projects'

Expand trigger terms with natural user language variations like 'check project setup', 'verify configuration', 'troubleshoot Conductor errors', 'project health check'

DimensionReasoningScore

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', 'diagnose 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 term 'Conductor project artifacts' provides some specificity to a particular tool/framework, but 'validates for completeness, consistency, and correctness' is quite generic and could overlap with other validation or linting skills. The 'when' triggers like 'diagnosing issues' are also broad.

2 / 3

Total

9

/

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.

Validation10 / 11 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

10

/

11

Passed

Repository
sickn33/antigravity-awesome-skills
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.