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.
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 covers the basics with an explicit 'Use when' clause, which is a strength. However, it stays at a category level rather than listing specific concrete actions, and the trigger terms could be more comprehensive to cover natural user language variations. The Optics framework name provides some distinctiveness but the broader styling terms create potential overlap risk.
Suggestions
Add more specific concrete actions, e.g., 'Apply Optics grid classes for layout, use spacing tokens (op-m-*, op-p-*), set typography scales, apply color variables, and compose UI components like buttons, cards, and modals.'
Expand trigger terms with common variations users might say, such as 'theme', 'UI styling', 'design tokens', 'CSS classes', 'responsive layout', or specific file extensions like '.css', '.scss'.
| 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 components', 'design tokens', 'class names', 'responsive', or file-type references like '.css', '.scss'. | 2 / 3 |
Distinctiveness Conflict Risk | The mention of 'Optics' as a specific design framework helps distinguish it, but broad terms like 'CSS', 'styling views', and 'design system guidelines' could overlap with other general CSS or styling skills. It could conflict with other design system or CSS utility framework skills. | 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 code examples, clear violation detection rules, and well-defined file paths. 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 checkpoints in workflows. The content would benefit from moving detailed examples to a referenced file and adding verification steps.
Suggestions
Move the full card and button component examples to a separate EXAMPLES.md file, keeping only a minimal example inline to demonstrate the token + BEM pattern.
Add a validation step to the component workflow, such as checking that all referenced tokens exist in tokens.json before considering the component complete.
Consolidate the three Quick Reference workflows into the main sections they summarize — the duplication adds tokens without adding clarity.
| 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 trimmed. The button example especially is verbose with multiple variants that demonstrate the same pattern repeatedly. | 2 / 3 |
Actionability | Provides fully executable CSS code examples, specific file paths for where to create/find components, concrete token naming patterns with correct/incorrect examples, and clear violation detection rules. 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. However, there are no validation checkpoints — no step to verify tokens exist in tokens.json before using them, no verification that the component renders correctly, and no feedback loop for catching styling errors. | 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. The skill tries to be both overview and detailed reference simultaneously, making it longer than necessary for a SKILL.md. | 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 | |
- Repository
- RoleModel/rolemodel-skills
- Commit
4d83977
- 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.