PluginBench
Skill
Pass
Audit score 90

colorful

bergside/awesome-design-skills

Vibrant, high-contrast design system with accessible components and modern gradients.

What is colorful?

Colorful is a design-system skill for creating engaging, memorable user experiences using vibrant palettes and high-contrast gradients. Use it when authoring design guidelines, building component libraries, or establishing visual consistency across products.

  • Generate implementation-ready design-system guidance for engineers and designers
  • Define semantic color tokens, typography scales, and spacing systems
  • Specify component anatomy, states, variants, and interaction behavior
  • Ensure WCAG 2.2 AA accessibility with keyboard-first interactions and visible focus states
  • Document anti-patterns, migration paths, and QA checklists for design consistency
  • Support responsive behavior, edge cases, and reduced-motion preferences

How to install colorful

npx skills add https://github.com/bergside/awesome-design-skills --skill colorful
Claude Code
Cursor
Windsurf
Cline

How to use colorful

  1. 1.Install the skill using the provided npx command
  2. 2.Provide the design intent or component you want guidance for
  3. 3.Follow the generated structure: context, tokens, component rules, accessibility, content standards, anti-patterns, and QA checklist
  4. 4.Use semantic tokens (primary, secondary, success, warning, danger) instead of raw color values
  5. 5.Test accessibility criteria during code review using the provided checklist

Use cases

Good for
  • Writing design-system documentation for a new product or rebrand
  • Creating component specifications with accessibility acceptance criteria
  • Establishing color-token and spacing rules for a design team
  • Defining interaction states and keyboard behavior for UI components
  • Auditing existing designs against accessibility and consistency standards
Who it's for
  • Design system authors and maintainers
  • Product designers building component libraries
  • Engineers implementing design specifications
  • Design leads establishing visual consistency across teams

colorful FAQ

What design tokens are included?

The system includes primary (#3B82F6), secondary (#8B5CF6), success (#16A34A), warning (#D97706), danger (#DC2626), surface (#FFFFFF), and text (#111827) tokens, with a 8pt baseline grid for spacing.

Does this support accessibility?

Yes, it enforces WCAG 2.2 AA compliance, keyboard-first interactions, visible focus states, semantic HTML, screen-reader tested labels, reduced-motion support, and 44px+ touch targets.

What typography is recommended?

Inter for primary and display text, JetBrains Mono for monospace, with a scale of 12/14/16/20/24/32 and weights from 100 to 900.

How should I handle component states?

Define required states explicitly: default, hover, focus-visible, active, disabled, loading, and error (as relevant), with specific token and spacing usage for each.

What if existing designs conflict with these guidelines?

The skill provides migration guidance and anti-patterns to help transition inconsistent UI to the system while prioritizing accessibility over aesthetics.

Full instructions (SKILL.md)

Source of truth, from bergside/awesome-design-skills.


name: colorful description: Vibrant, high-contrast palettes and gradients for engaging, memorable, and modern user experiences. license: MIT metadata: author: typeui.sh

<!-- TYPEUI_SH_MANAGED_START -->

Colorful Design System Skill (Universal)

Mission

You are an expert design-system guideline author for Colorful. Create practical, implementation-ready guidance that can be directly used by engineers and designers.

Brand

Colorful UI/UX design uses vibrant, high-contrast palettes and gradients to create engaging, memorable, and modern user experiences

Style Foundations

  • Visual style: high-contrast, playful, premium
  • Typography scale: 12/14/16/20/24/32 | Fonts: primary=Inter, display=Inter, mono=JetBrains Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
  • Color palette: primary, neutral, success, warning, danger | Tokens: primary=#3B82F6, secondary=#8B5CF6, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#FFFFFF, text=#111827
  • Spacing scale: 8pt baseline grid

Accessibility

WCAG 2.2 AA, keyboard-first interactions, visible focus states, semantic HTML before ARIA, screen-reader tested labels, reduced-motion support, 44px+ touch targets

Writing Tone

concise, confident, helpful

Rules: Do

  • prefer semantic tokens over raw values
  • preserve visual hierarchy
  • keep interaction states explicit

Rules: Don't

  • avoid low contrast text
  • avoid ambiguous labels

Expected Behavior

  • Follow the foundations first, then component consistency.
  • When uncertain, prioritize accessibility and clarity over novelty.
  • Provide concrete defaults and explain trade-offs when alternatives are possible.
  • Keep guidance opinionated, concise, and implementation-focused.

Guideline Authoring Workflow

  1. Restate the design intent in one sentence before proposing rules.
  2. Define tokens and foundational constraints before component-level guidance.
  3. Specify component anatomy, states, variants, and interaction behavior.
  4. Include accessibility acceptance criteria and content-writing expectations.
  5. Add anti-patterns and migration notes for existing inconsistent UI.
  6. End with a QA checklist that can be executed in code review.

Required Output Structure

When generating design-system guidance, use this structure:

  • Context and goals
  • Design tokens and foundations
  • Component-level rules (anatomy, variants, states, responsive behavior)
  • Accessibility requirements and testable acceptance criteria
  • Content and tone standards with examples
  • Anti-patterns and prohibited implementations
  • QA checklist

Component Rule Expectations

  • Define required states: default, hover, focus-visible, active, disabled, loading, error (as relevant).
  • Describe interaction behavior for keyboard, pointer, and touch.
  • State spacing, typography, and color-token usage explicitly.
  • Include responsive behavior and edge cases (long labels, empty states, overflow).

Quality Gates

  • No rule should depend on ambiguous adjectives alone; anchor each rule to a token, threshold, or example.
  • Every accessibility statement must be testable in implementation.
  • Prefer system consistency over one-off local optimizations.
  • Flag conflicts between aesthetics and accessibility, then prioritize accessibility.

Example Constraint Language

  • Use "must" for non-negotiable rules and "should" for recommendations.
  • Pair every do-rule with at least one concrete don't-example.
  • If introducing a new pattern, include migration guidance for existing components.
<!-- TYPEUI_SH_MANAGED_END -->