Use the Optics design framework for styling applications. Apply Optics classes for layout, spacing, typography, colors, and components. Use when working on CSS, styling views, or implementing design system guidelines.
57
66%
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/optics-context/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 is functional and well-structured with a clear 'Use when' clause, making it complete. However, it stays at a category level rather than listing specific concrete actions, and its trigger terms could overlap with generic CSS or styling skills. The mention of 'Optics' as a named framework provides some distinctiveness but the broader triggers remain somewhat generic.
Suggestions
Add more specific concrete actions, e.g., 'Apply Optics grid classes, spacing utilities, typography scales, color tokens, and pre-built component styles'
Include additional natural trigger terms users might say, such as 'theme', 'UI classes', 'design tokens', '.css files', or 'style sheets'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Optics design framework, CSS styling) and lists categories of actions (layout, spacing, typography, colors, components), but doesn't describe specific concrete actions like 'apply grid classes', 'set color tokens', or 'use typography scale'. The actions are category-level rather than task-level. | 2 / 3 |
Completeness | Clearly answers both 'what' (apply Optics classes for layout, spacing, typography, colors, and components) and 'when' (Use when working on CSS, styling views, or implementing design system guidelines). The 'Use when...' clause is explicit with trigger scenarios. | 3 / 3 |
Trigger Term Quality | Includes some relevant keywords like 'CSS', 'styling', 'design system', 'Optics', and category terms like 'layout', 'spacing', 'typography', 'colors'. However, it misses common variations users might say such as 'theme', 'UI styles', 'class names', 'design tokens', or specific file types like '.css', '.scss'. | 2 / 3 |
Distinctiveness Conflict Risk | The mention of 'Optics' as a specific design framework helps distinguish it, but the broader triggers like 'CSS', 'styling views', and 'design system guidelines' could overlap with general CSS skills or other design system skills. It's somewhat specific but not fully distinct. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
64%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a solid, actionable design system skill with concrete examples and clear violation detection patterns. Its main weaknesses are verbosity in the component examples section (the button example alone is ~50 lines demonstrating a repetitive pattern) and the lack of validation/verification steps in the component creation workflow. The quick reference section at the end effectively summarizes the workflows.
Suggestions
Condense the button component example to show only the base block and one modifier variant, noting the pattern applies to other variants — this would save ~30 lines while preserving clarity.
Add a validation step to the component workflow, such as verifying the import in application.scss loads correctly or checking the component renders as expected in the browser.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient and avoids explaining basic CSS concepts, but the two full component examples (card and button) are quite lengthy and could be condensed. The button example especially is verbose with multiple variants that demonstrate the same pattern repeatedly. | 2 / 3 |
Actionability | Provides fully executable CSS examples, specific file paths for where to find and create components, concrete token naming patterns with correct/incorrect examples, and clear violation detection patterns. The guidance is copy-paste ready and specific to the project structure. | 3 / 3 |
Workflow Clarity | The discovery, token, and component workflows are clearly sequenced in the Quick Reference section, but there are no validation checkpoints. For a styling skill involving file creation and imports, there's no step to verify the component renders correctly or that the import in application.scss works. | 2 / 3 |
Progressive Disclosure | References to `assets/components.json` and `assets/tokens.json` are well-signaled, but the inline content is heavy — the full button and card component examples could be in a separate examples file. No bundle files were provided, so the referenced assets can't be verified, but the structure is reasonable for a single-file skill. | 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.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
metadata_version | 'metadata.version' is missing | Warning |
Total | 10 / 11 Passed | |
72e8136
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.