Intentional design thinking for interfaces, components, and systems. Use when the user asks to "build a UI", "design a page", "create a component", "make this look good", "design an API", "design a system", or any task where aesthetic or structural design decisions matter.
69
62%
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/design/SKILL.mdQuality
Discovery
82%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 description has strong completeness with an explicit 'Use when...' clause containing multiple natural trigger phrases. Its main weakness is the breadth of scope—covering UI design, API design, and system design under one umbrella—which reduces both specificity of concrete actions and distinctiveness from other potential skills. The description would benefit from more concrete action verbs describing what the skill actually does.
Suggestions
Add specific concrete actions the skill performs, e.g., 'Applies layout principles, selects typography and color schemes, structures component hierarchies, and defines visual consistency patterns.'
Consider narrowing scope or clarifying boundaries to reduce overlap with frontend development or system architecture skills—e.g., specify that this focuses on design decisions and aesthetics rather than implementation.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain ('interfaces, components, and systems') and the general approach ('intentional design thinking'), but does not list specific concrete actions like 'create wireframes', 'define color palettes', 'structure component hierarchies', etc. The capabilities remain somewhat abstract. | 2 / 3 |
Completeness | The description clearly answers both 'what' (intentional design thinking for interfaces, components, and systems) and 'when' (explicit 'Use when...' clause with multiple trigger phrases and a catch-all condition about aesthetic or structural design decisions). | 3 / 3 |
Trigger Term Quality | The description includes a strong set of natural trigger phrases users would actually say: 'build a UI', 'design a page', 'create a component', 'make this look good', 'design an API', 'design a system'. These cover both visual and structural design requests well. | 3 / 3 |
Distinctiveness Conflict Risk | While the trigger terms are helpful, the scope is quite broad—covering UI design, API design, and system design could overlap with dedicated skills for frontend development, API development, or system architecture. Terms like 'build a UI' or 'create a component' could easily conflict with a general frontend/React skill. | 2 / 3 |
Total | 10 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill reads more as a design philosophy manifesto than actionable guidance. While it's well-structured and appropriately scoped as an overview with good cross-references, it critically lacks concrete examples — no code snippets, no before/after comparisons, no specific font pairings, no example color palettes, no sample API designs. Claude would struggle to translate these abstract principles into specific implementation decisions.
Suggestions
Add concrete, executable examples: a CSS snippet showing a distinctive color palette with variables, a font pairing example with import statements, or a before/after HTML/CSS comparison showing 'generic' vs 'intentional' design.
Replace vague directives like 'Choose distinctive, characterful fonts' with specific actionable guidance, e.g., a curated list of recommended Google Fonts pairings or a concrete example of a cohesive palette definition.
Add a concrete API design example showing a good vs bad interface, rather than just listing principles like 'Least Astonishment' that Claude already understands.
Include at least one complete mini-example showing the full design thinking workflow applied to a real scenario (e.g., designing a landing page from purpose through implementation).
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Generally efficient but includes some philosophical padding ('Generic defaults are the enemy', 'Bold maximalism and refined minimalism both work. Timid middle ground does not.') that reads more like a manifesto than actionable instruction. The visual design section is reasonably dense but could be tighter. | 2 / 3 |
Actionability | Almost entirely abstract guidance with no concrete code, commands, or executable examples. Statements like 'Choose distinctive, characterful fonts' and 'Commit to a cohesive palette' are vague direction rather than actionable instruction. No CSS snippets, no example color palettes, no concrete API design examples, no before/after comparisons. | 1 / 3 |
Workflow Clarity | The 'Design Thinking' section provides a reasonable 4-step sequence, and 'The Test' provides a validation checklist. However, there's no clear workflow connecting the different design domains (visual, API, system), and no feedback loops or error recovery steps for when designs don't pass the test. | 2 / 3 |
Progressive Disclosure | Well-organized with clear sections covering different design domains, appropriate length for a SKILL.md overview, and a 'See Also' section with one-level-deep references to related skills and resources. | 3 / 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.
c3b1fc2
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.