Extract and consolidate reusable components, design tokens, and patterns into your design system. Identifies opportunities for systematic reuse and enriches your component library. Use when the user asks to create components, refactor repeated UI patterns, build a design system, or extract tokens.
77
71%
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 ./.cursor/skills/extract/SKILL.mdQuality
Discovery
92%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 strong description that clearly articulates specific capabilities and includes an explicit 'Use when...' clause with natural trigger terms. The main weakness is a slight risk of overlap with general UI/frontend development skills, though the focus on design systems and token extraction helps differentiate it. Minor note: uses second person 'your' twice, but the primary verbs are in third person so the impact is minimal.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: 'extract and consolidate reusable components', 'design tokens', 'patterns', 'identifies opportunities for systematic reuse', and 'enriches your component library'. These are concrete, actionable capabilities. | 3 / 3 |
Completeness | Clearly answers both 'what' (extract/consolidate reusable components, design tokens, patterns; identify reuse opportunities; enrich component library) and 'when' with an explicit 'Use when...' clause listing four trigger scenarios. | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'create components', 'refactor repeated UI patterns', 'build a design system', 'extract tokens', 'component library', 'design tokens'. These cover common variations of how users would phrase such requests. | 3 / 3 |
Distinctiveness Conflict Risk | While 'design system' and 'design tokens' are fairly specific, terms like 'reusable components' and 'UI patterns' could overlap with general UI development or component creation skills. The description carves out a niche but could still conflict with broader frontend or UI skills. | 2 / 3 |
Total | 11 / 12 Passed |
Implementation
50%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides a well-structured conceptual framework for design system extraction with clear phases, but it lacks the concrete, executable examples that would make it truly actionable. The guidance remains at a descriptive level without code snippets, specific file structures, or validation commands. It also includes some unnecessary elaboration on concepts Claude already understands.
Suggestions
Add concrete code examples: a sample design token file (e.g., JSON/CSS custom properties), a component template with TypeScript props, and specific grep/search commands for finding patterns.
Add explicit validation checkpoints in the Migrate phase, such as visual regression testing commands, diff checks, or a verification checklist to confirm parity before deleting old code.
Consider splitting detailed guidance (e.g., token naming conventions, component API design patterns, accessibility checklist) into referenced files to keep the main skill lean while providing depth.
Remove explanatory content Claude already knows (e.g., listing 'buttons, cards, inputs' as examples of components, explaining what ARIA is) to improve token efficiency.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is reasonably structured but includes some unnecessary elaboration that Claude would already know (e.g., explaining what design tokens are, listing obvious examples like 'buttons, cards, inputs'). The 'NEVER' list and closing aphorism add some padding. Could be tightened by ~30%. | 2 / 3 |
Actionability | The skill provides structured guidance with clear categories of action, but lacks any concrete code examples, specific commands, or executable snippets. Everything remains at the level of description and checklists rather than copy-paste-ready implementation. No example of a token file, component template, or grep command is provided. | 2 / 3 |
Workflow Clarity | The multi-step workflow (Discover → Plan → Extract → Migrate → Document) is clearly sequenced, but validation checkpoints are largely missing. The 'Migrate' section mentions 'Test thoroughly' but provides no specific validation steps or feedback loops for error recovery. For a workflow involving potentially destructive refactoring and batch replacements, this gaps caps the score at 2. | 2 / 3 |
Progressive Disclosure | The content is organized into clear sections with headers, which is good. However, it's a monolithic document with no references to external files for detailed guidance (e.g., component templates, token naming conventions, migration scripts). For a topic this broad, some content could be split into referenced files for component patterns, token structures, etc. | 2 / 3 |
Total | 8 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
db1add7
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.