design-system
Audit, document, or extend your design system. Use when checking for naming inconsistencies or hardcoded values across components, writing documentation for a component's variants, states, and accessibility notes, or designing a new pattern that fits the existing system.
68
61%
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 ./design/skills/design-system/SKILL.mdQuality
Discovery
85%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 defines what the skill does and when to use it, with an explicit 'Use when...' clause covering multiple trigger scenarios. The specificity of actions like checking naming inconsistencies and documenting component variants is excellent. The main weakness is that trigger term coverage could be broader to capture more natural user phrasings related to design systems.
Suggestions
Add additional natural trigger terms users might say, such as 'tokens', 'theme', 'style guide', 'component library', or 'UI kit' to improve discoverability.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: 'audit', 'document', 'extend' a design system, plus elaborates with checking naming inconsistencies, hardcoded values, writing documentation for variants/states/accessibility notes, and designing new patterns. | 3 / 3 |
Completeness | Clearly answers both 'what' (audit, document, or extend your design system) and 'when' with an explicit 'Use when...' clause covering three distinct trigger scenarios: checking inconsistencies, writing component documentation, and designing new patterns. | 3 / 3 |
Trigger Term Quality | Includes relevant terms like 'design system', 'naming inconsistencies', 'hardcoded values', 'components', 'variants', 'states', 'accessibility', but misses common user phrasings like 'tokens', 'theme', 'style guide', 'component library', or 'UI patterns' that users might naturally say. | 2 / 3 |
Distinctiveness Conflict Risk | The focus on design systems specifically—auditing naming conventions, hardcoded values, component documentation with variants/states/accessibility, and pattern design—creates a clear niche that is unlikely to conflict with general coding, documentation, or UI development skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
37%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill provides excellent output templates that give Claude clear formatting targets for audit, documentation, and extension tasks. However, it spends tokens explaining design system concepts Claude already knows while lacking the actual procedural steps needed to perform each task. The gap between 'here's what the output looks like' and 'here's how to produce it' significantly limits actionability.
Suggestions
Replace the 'Components of a Design System' section with actual procedural steps for each workflow (e.g., for audit: 'grep for hardcoded hex values', 'check naming conventions against pattern X', 'compare component prop interfaces').
Add explicit workflow sequences for each command—especially the audit, which needs steps like 'scan files → identify issues → categorize → score → prioritize' with validation checkpoints.
Move the three large output templates to separate reference files (e.g., AUDIT_TEMPLATE.md, DOCUMENT_TEMPLATE.md, EXTEND_TEMPLATE.md) and keep only brief summaries in the main skill.
Add concrete examples of what to look for during an audit (e.g., regex patterns for hardcoded colors, naming convention rules to check against) rather than just the output format.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill includes some useful structural content but is verbose in areas Claude already understands—listing what design tokens are, what components consist of, and what patterns are is largely unnecessary context. The 'Components of a Design System' section explains basic concepts Claude already knows well. | 2 / 3 |
Actionability | The output templates are concrete and well-structured, giving Claude clear formats to follow. However, the actual audit/document/extend processes lack executable steps—there's no guidance on HOW to perform an audit (e.g., what to grep for, how to detect hardcoded values), just what the output should look like. | 2 / 3 |
Workflow Clarity | There are no sequenced steps for any of the three workflows (audit, document, extend). The skill shows output templates but never describes the process to produce them. For an audit involving potentially destructive recommendations or batch changes, there are no validation checkpoints or feedback loops. | 1 / 3 |
Progressive Disclosure | The skill references CONNECTORS.md appropriately and organizes content into clear sections. However, the three large output templates make the file quite long and could be split into separate reference files. The content is well-structured with headers but is monolithic in practice. | 2 / 3 |
Total | 7 / 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 |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
- Repository
- anthropics/knowledge-work-plugins
- Commit
f55b539
- 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.