Help us improve
Share bugs, ideas, or general feedback.
From designpowers
Aligns designs with existing systems or builds new ones via inventory, token architecture, component specs, naming conventions, accessibility checks, and consistency audits.
npx claudepluginhub owl-listener/designpowersHow this skill is triggered — by the user, by Claude, or both
Slash command
/designpowers:design-system-alignmentThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A design system is a shared language. When components are consistent, accessible, and well-documented, every new screen starts from a strong foundation. This skill ensures design work aligns with existing systems or builds new ones with the right properties.
Audits design systems for naming inconsistencies/hardcoded values, documents component variants/states/accessibility, extends with new tokens/patterns fitting existing system.
Build or audit a design system: component library, design tokens, naming conventions, contribution model, documentation. Use when teams are inconsistent across products.
Establishes design system consistency with layered design tokens (primitive, semantic, component), CSS custom properties, atomic design methodology, token governance, and codebase audits for visual uniformity.
Share bugs, ideas, or general feedback.
A design system is a shared language. When components are consistent, accessible, and well-documented, every new screen starts from a strong foundation. This skill ensures design work aligns with existing systems or builds new ones with the right properties.
If a design system exists, catalogue:
If no system exists, document what patterns are already in use (even informally).
Design tokens are the atoms of the system. Structure them in layers:
Global tokens — raw values
color-blue-500: #3B82F6
spacing-4: 16px
font-size-base: 1rem
Semantic tokens — purpose-driven aliases
color-primary: {color-blue-500}
color-error: {color-red-600}
spacing-element: {spacing-4}
font-size-body: {font-size-base}
Component tokens — component-specific overrides
button-background: {color-primary}
button-padding: {spacing-3} {spacing-4}
input-border-color: {color-neutral-300}
Every token must meet accessibility requirements at the semantic level — if color-primary is used for text, it must have sufficient contrast against its background token.
For each component, document:
## [Component Name]
**Purpose:** [What this component is for]
**Variants:** [e.g., primary, secondary, ghost, destructive]
**States:** [default, hover, focus, active, disabled, error, loading]
**Accessibility:**
- Role: [ARIA role if not implicit]
- Label: [How it is labelled — visible text, aria-label, aria-labelledby]
- Keyboard: [How to interact via keyboard]
- Screen reader: [What is announced in each state]
- Focus: [Focus indicator style, focus order]
**Tokens used:** [Which design tokens this component references]
**Do:** [Correct usage examples]
**Do not:** [Incorrect usage examples]
Consistent naming makes a system learnable:
AlertDialog not Modal2 or PopupThing--disabled, --error, --active)For every component in the system, verify:
| Check | Requirement |
|---|---|
| Colour contrast | All text/background pairings meet WCAG AA minimum |
| Keyboard access | Every interactive component is reachable and operable via keyboard |
| Screen reader | Every component announces its role, name, state, and value correctly |
| Focus indicator | Every focusable element has a visible focus ring |
| Touch targets | All interactive elements meet 44x44px minimum |
| Motion | All animations respect prefers-reduced-motion |
| Resize | Components function at 200% zoom |
A design system only works if people use it. Ensure:
ui-composition (when components need to align with a system)ui-composition (visual decisions), accessible-content (content patterns within components)designpowers-critique