optics-context
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.
71
66%
Does it follow best practices?
Impact
Pending
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 that addresses both what the skill does and when to use it. Its main weaknesses are moderate specificity—listing categories rather than concrete actions—and some overlap risk with other styling/CSS skills due to generic trigger terms. Adding more specific Optics-related terminology and concrete actions would strengthen it.
Suggestions
Add more specific concrete actions, e.g., 'Apply Optics utility classes for flex/grid layout, margin/padding spacing tokens, type scale classes, and color variables'.
Include additional natural trigger terms users might say, such as 'theme', 'UI styles', '.css files', '.scss', or 'class names'.
| 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 'configure responsive breakpoints'. | 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), with an explicit 'Use when' clause. | 3 / 3 |
Trigger Term Quality | Includes some relevant keywords like 'CSS', 'styling', 'design system', 'Optics', 'layout', 'spacing', 'typography', 'colors', and 'components'. However, it misses common variations users might say like 'styles', 'theme', 'UI framework', 'class names', 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 terms 'CSS', 'styling views', and 'design system guidelines' could overlap with other CSS or design-related 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 skill that provides concrete guidance for using the Optics design framework with executable CSS examples and clear violation detection patterns. Its main weaknesses are verbosity (especially the lengthy button example that could be externalized) and missing validation steps in the component creation workflow. The content would benefit from trimming redundant sections and adding verification checkpoints.
Suggestions
Move the detailed card and button component examples to a separate EXAMPLES.md file, keeping only one brief inline example to demonstrate the pattern
Add a validation step to the component workflow, e.g., 'Verify all token names exist in assets/tokens.json before committing' or a grep/search command to confirm token validity
Remove the Quick Reference section at the bottom, as it largely duplicates the workflows already described in the body
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient but includes some redundancy—the button component example is quite lengthy and the quick reference section largely repeats information already covered in the body. The card and button examples together are verbose when one would suffice to demonstrate the pattern. | 2 / 3 |
Actionability | Provides fully executable CSS examples with correct token usage, concrete file paths for where to create/find components, specific token naming patterns with correct/incorrect examples, and clear BEM structure demonstrations. The violation detection section with ❌/✅ examples is particularly actionable. | 3 / 3 |
Workflow Clarity | The discovery, token, and component workflows are clearly sequenced, but there are no validation checkpoints. When creating new components or replacing hard-coded values with tokens, there's no step to verify the token exists in tokens.json or that the component renders correctly. For a styling system where wrong token names fail silently, validation steps would be important. | 2 / 3 |
Progressive Disclosure | References to external files (components.json, tokens.json) are well-signaled, but the inline content is heavy—particularly the two full component examples that could be in a separate EXAMPLES.md. The skill would benefit from moving detailed examples to a referenced file and keeping SKILL.md as a concise overview. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
metadata_version | 'metadata.version' is missing | Warning |
metadata_field | 'metadata' should map string keys to string values | Warning |
Total | 9 / 11 Passed | |
- Repository
- RoleModel/rolemodel-skills
- Commit
097ad6b
- 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.