Vendor-agnostic lab automation framework. Use when controlling multiple equipment types (Hamilton, Tecan, Opentrons, plate readers, pumps) or needing unified programming across different vendors. Best for complex workflows, multi-vendor setups, simulation. For Opentrons-only protocols with official API, opentrons-integration may be simpler.
75
67%
Does it follow best practices?
Impact
87%
1.20xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./scientific-skills/pylabrobot/SKILL.mdQuality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is an excellent skill description that clearly defines its niche in vendor-agnostic lab automation, lists specific vendor names and equipment types as natural trigger terms, and explicitly addresses both when to use it and when not to use it. The disambiguation against the related opentrons-integration skill is particularly well done, reducing conflict risk. The description is concise yet comprehensive.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions and domains: controlling equipment types (Hamilton, Tecan, Opentrons, plate readers, pumps), unified programming across vendors, complex workflows, multi-vendor setups, and simulation. | 3 / 3 |
Completeness | Clearly answers both 'what' (vendor-agnostic lab automation framework for controlling multiple equipment types with unified programming) and 'when' (explicit 'Use when' clause specifying multi-vendor setups, complex workflows, simulation). Also includes a helpful disambiguation note about when to use an alternative skill. | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural terms a user in lab automation would use: specific vendor names (Hamilton, Tecan, Opentrons), equipment types (plate readers, pumps), and domain terms (lab automation, multi-vendor, simulation, workflows). These are highly natural keywords for the target audience. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with a clear niche in vendor-agnostic lab automation. The explicit disambiguation against 'opentrons-integration' for Opentrons-only protocols directly addresses potential conflict, making it very clear when to choose this skill versus the alternative. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
35%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is well-structured with good progressive disclosure to reference files, but suffers significantly from verbosity—it explains too much context Claude already knows and duplicates content from reference files inline. The code examples are a strength but are incomplete (undefined variables in Quick Start) and lack validation/error handling steps critical for hardware automation workflows.
Suggestions
Cut the 'When to Use This Skill' section entirely and reduce 'Core Capabilities' to a brief table or list of one-liners pointing to reference files, eliminating the sub-bullet descriptions that duplicate reference content.
Fix the Quick Start code to be fully executable—define plate and tip_rack variables before using them, or show a complete minimal working example.
Add explicit validation checkpoints to workflow examples: verify setup succeeded (e.g., check connection), validate deck assignments, and show error handling patterns for hardware failures.
Remove the 'Overview' paragraph and generic Best Practices items (like 'use clear names' and 'implement error handling') that Claude already knows—keep only PyLabRobot-specific guidance.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose. The 'When to Use This Skill' section is 9 bullet points of obvious context Claude doesn't need. The 'Core Capabilities' section repeats information that belongs in the referenced files. The overview explains what PyLabRobot is despite the description already covering this. Significant token waste on enumerating every supported device and capability area with sub-bullets. | 1 / 3 |
Actionability | The Quick Start and Common Workflows sections provide executable Python code examples, but the code is incomplete (e.g., plate and tip_rack variables are used before being defined in the Quick Start). The Best Practices are generic advice rather than concrete, actionable instructions. Many sections describe capabilities rather than instruct. | 2 / 3 |
Workflow Clarity | The Common Workflows section shows sequential steps but lacks validation checkpoints. There's no error handling shown, no verification that setup succeeded, no feedback loops for hardware failures. The 'Start with Simulation' best practice is mentioned but not integrated into the workflow examples. For hardware automation (destructive/batch operations), missing validation caps this at 2. | 2 / 3 |
Progressive Disclosure | Good use of references/ directory with clear file pointers, but the SKILL.md itself contains too much inline content that duplicates what should be in the reference files. The Core Capabilities section is essentially a summary of all six reference files, bloating the overview. The 'Working with References' section is helpful but the overall balance is off. | 2 / 3 |
Total | 7 / 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 |
|---|---|---|
metadata_version | 'metadata.version' is missing | Warning |
Total | 10 / 11 Passed | |
b58ad7e
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.