About design-consistency-auditor
A skill for reviewing frontend projects for consistency with their established design system. It checks semantic color tokens, spacing, component patterns, typography, and layout, while directing accessibility conformance to a separate pass.
Key features
- 01Check semantic color-token usage
- 02Find hardcoded and arbitrary values
- 03Review component-pattern consistency
- 04Check spacing and layout scales
- 05Review typography hierarchy
- 06Separate accessibility checks
Use cases
- 01Audit color-token use across an app
- 02Find one-off styles duplicating components
- 03Review new features against design standards
- 04Identify visual divergence between screens
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/design-consistency-auditorin Claude Code to confirm it loaded.
Bundled files
References and scripts installed along with SKILL.md.
plugin.jsonREADME.mdexamples/audit-report-template.mdquick-audit-checklist.mdreferences/full-guide.mdDetails
From the project READMEDesign Consistency Auditor
Before auditing, discover the project's frontend structure from documentation.
Ensures:
- Color palettes are used consistently through semantic tokens
- Spacing stays on the project's scale
- Components maintain visual harmony across screens
- The design system is applied instead of duplicated
- No design debt accumulates
When to Use
- Auditing design-token consistency across apps
- Reviewing color palette usage and hunting hardcoded hex values
- Checking UI/UX patterns for screen-to-screen divergence
- Spotting one-off classes that duplicate a design-system component
- Reviewing new features against the established design standards
Accessibility conformance is a separate pass — use accessibility for WCAG, ARIA,
keyboard access, and contrast.
Quick Reference
Color Rules
DO: Use shadcn semantic tokens (bg-background, bg-card, bg-primary, text-muted-foreground, border-border)
DON'T: Hardcode hex colors (#000000) or arbitrary values (bg-[#123456])
Component Patterns
Discover the project's component class conventions from its design system or existing codebase. Common patterns to look for:
- Cards: the shadcn
Cardor the project's own card component - App shells / layouts: project-specific shell wrapper class
- Modals / dialogs: project dialog component pattern
- Inputs: project form input class or component
- Buttons: project button variants (primary, secondary, ghost)
Identify the actual class names from the codebase before auditing — do not assume a specific naming convention.
Spacing
DO: Use Tailwind scale (p-4, m-6, gap-4)
DON'T: Use arbitrary values (p-[17px])
Accessibility
- Semantic HTML (
<button>,<nav>,<main>) - ARIA labels on interactive elements
- 4.5:1 contrast for text, 3:1 for UI
- Focus states:
focus:outline-none focus:ring-2 focus:ring-primary
Responsive
- Mobile-first with
sm:,md:,lg:,xl:modifiers - Responsive typography:
text-3xl sm:text-4xl
Audit Phases
- Color Palette - Scan for hardcoded colors, verify theme tokens
- Component Patterns - Check cards, buttons, forms use theme classes
- Spacing & Layout - Verify consistent spacing scale
- Typography - Check heading hierarchy and text styles
- Accessibility - Run automated checks, keyboard testing
AI Slop Prevention
Audit for generic "AI-generated" aesthetics:
- Generic fonts (Inter, Roboto everywhere)
- Purple gradients on white
- Predictable layouts without character
- Safe, boring color choices
Push for distinctive, branded designs with personality.
For detailed checklists, examples, reporting templates, and audit commands, see: references/full-guide.md
Related
audit— a scored 0-4 sweep across accessibility, performance, theming, responsive design, and anti-patterns when no single dimension is named.accessibility— WCAG 2.1 AA conformance, ARIA, keyboard access, and screen-reader verification.