create-color
Generate color annotation specifications mapping UI elements to design tokens. Use when the user mentions "color", "color annotation", "color spec", "tokens", "design tokens", or wants to document which color tokens a component uses.
77
72%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./.cursor/skills/create-color/SKILL.mdQuality
Discovery
89%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 a well-structured description with an explicit 'Use when...' clause and strong trigger term coverage. Its main weakness is that the 'what' portion could be more specific by listing additional concrete actions beyond the single high-level capability. Overall, it's a solid description that would perform well in skill selection.
Suggestions
Add 2-3 more specific actions to the 'what' portion, e.g., 'Generate color annotation specifications mapping UI elements to design tokens, produce token-to-hex reference tables, and create component-level color documentation.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (color annotation specifications) and one core action (mapping UI elements to design tokens), but doesn't list multiple concrete actions like generating token tables, exporting specs, or validating token usage. | 2 / 3 |
Completeness | Clearly answers both 'what' (generate color annotation specifications mapping UI elements to design tokens) and 'when' (explicit 'Use when...' clause with specific trigger terms and a scenario description). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms: 'color', 'color annotation', 'color spec', 'tokens', 'design tokens', and the use-case phrase 'document which color tokens a component uses' covers how users would naturally phrase this need. | 3 / 3 |
Distinctiveness Conflict Risk | This is a very specific niche — color annotation specs and design token mapping — that is unlikely to conflict with general design, theming, or code generation skills. The trigger terms are distinct and narrowly scoped. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
55%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill excels at actionability and workflow clarity — every step has executable code, clear sequencing, and validation checkpoints. However, it is severely hampered by its massive size (~800+ lines), with enormous inline JavaScript blocks that should be extracted into referenced files. The monolithic structure makes it extremely token-inefficient and difficult to navigate, undermining the progressive disclosure principle.
Suggestions
Extract the large JavaScript code blocks (Step 4b extraction script, Step 11 Strategy A/B rendering scripts) into separate referenced files (e.g., `scripts/extraction.js`, `scripts/render-strategy-a.js`) and reference them with brief descriptions of inputs/outputs.
Move the MCP adapter table to a separate shared reference file (e.g., `MCP_ADAPTER.md`) since it's reusable across skills and consumes significant tokens.
Deduplicate the Strategy A and Strategy B rendering scripts by extracting shared helper functions (loadAllFonts, loadFontWithFallback, enableNestedBooleans, variant matching) into a common utilities reference.
Consolidate the Notes section at the end — many bullet points repeat information already stated in the workflow steps, adding redundant tokens without new value.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | This skill is extremely verbose at ~800+ lines. It includes massive inline JavaScript code blocks that could be referenced from external files, extensive implementation details about font loading and node traversal that Claude doesn't need explained inline, and repetitive patterns across Strategy A and Strategy B scripts that share ~70% identical code. | 1 / 3 |
Actionability | The skill provides fully executable JavaScript code for every step, concrete placeholder patterns for variable substitution, specific MCP tool calls with exact parameter names, and complete copy-paste-ready scripts. Every step has precise, executable guidance. | 3 / 3 |
Workflow Clarity | The workflow has a clear numbered checklist with explicit validation at Step 12 (visual validation with up to 3 fix iterations), container detection checks at Step 4c, extraction validation, and an audit step (Step 8) that re-reads instruction rules. The multi-step process is well-sequenced with clear dependencies between steps. | 3 / 3 |
Progressive Disclosure | This is a monolithic wall of content with massive inline code blocks that should be in separate files. The MCP adapter table, extraction script (~150 lines), Strategy A rendering script (~200 lines), and Strategy B rendering script (~200 lines) are all inline rather than referenced. The skill references agent-color-instruction.md but doesn't offload its own bulk content appropriately. | 1 / 3 |
Total | 8 / 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 |
|---|---|---|
skill_md_line_count | SKILL.md is long (1322 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
- Repository
- redongreen/uSpec
- Commit
4eae941
- 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.