premium

---
name: premium
description: Warm, professional design with burgundy red brand accents, large rounded cards, alternating sections, and bold typography.
license: MIT
metadata:
  author: Aimeos
---

# Premium Theme Design System

## Mission
You are an expert frontend developer for the Premium theme.
Follow these guidelines to produce visually consistent, accessible markup and styles.

## Brand
Warm, professional, confident. Cool neutral background (#F8F9FA) with burgundy red brand accents (#991B1B). Clean flat surfaces, generous whitespace, bold typography, alternating section backgrounds. Built on Pico CSS with `--pico-*` custom property overrides.

## Style Foundations
- Visual style: modern, clean, professional. No texture or pattern on backgrounds, flat surfaces with subtle drop-shadows
- Typography: Font=ui-sans-serif, sans-serif | Monospace=ui-monospace, monospace | weights=400 (body/description text), 500 (h3-h6/labels/nav), 600 (h1-h2/buttons/brand) | Base size: 1.1875rem | Sizes use calc(var(--pico-font-size) * multiplier): h1=2.25x/2.5x(768px)/2.75x(hero)/3.75x(hero 768px), h2=1.6x/1.75x(768px), h3=0.9x, h4=0.8x | line-height: body=1.625, h1=1.1, h2=1.2, h3=1.3, h4=1.4 | letter-spacing: display=-0.03em, hero=-0.04em
- Color tokens: --pico-color=#0F172A, --pico-background-color=#F8F9FA, --pico-muted-color=#435064, --pico-muted-border-color=#0F172A14, --pico-contrast=#0F172A, --pico-contrast-inverse=#FFFFFF, --pico-primary=#991B1B, --pico-primary-hover=#7F1D1D, --pico-secondary=#4338CA, --pico-secondary-hover=#3730A3, --pico-text-selection-color=#DBEAFE | Surfaces: #FFFFFF for cards, #F1F5F9 for alternating sections, #0F172A for footer | Heading colors: h1-h4=#0F172A, h5=#334155, h6=#435064
- Border radius: base --pico-border-radius=0.5rem, use calc multipliers: 1x=0.5rem (buttons/inputs), 1.5x=0.75rem (code/form focus), 2x=1rem (blog items/images inside containers), 3x=1.5rem (FAQ/TOC), 4x=2rem (cards/containers/hero images/pricing) | Shadows: box-shadow: 0 1px 3px #0F172A0A, 0 1px 2px #0F172A06; elevated hover: 0 0.5rem 2rem #0F172A0F; drop-shadow: 0 1.5rem 3rem #0F172A14
- Max widths: 1280px (header/footer/page/docs/blog), 1200px (main container), 960px (CMS content), 50rem (text), 38rem (hero paragraph) | Breakpoints: 576px, 768px, 992px, 1024px
- Components: hero (large heading with pill badge subtitle), cards (1->3 col grid with hover lift), blog (featured+list with date badges), questions/FAQ (details/summary accordion), contact form, toc, slideshow, article, search dialog, docs sidebar (20rem, sticky), dark footer
- Buttons: rounded (0.5rem radius), primary=burgundy bg (#991B1B), secondary=white bg with border | Padding: 0.875rem 1.5rem

## Accessibility
WCAG 2.2 AA. Skip-to-content link. Focus: 2px solid primary, offset 2px; inputs: 0 0 0 3px #2563EB1A. Min touch target: 2.25rem. prefers-reduced-motion respected. Semantic HTML (nav aria-label, dialog, details). RTL support.

## Writing Tone
concise, confident, professional

## Rules: Do
- Use --pico-* custom properties for all colors, spacing, and typography
- Use calc(var(--pico-border-radius) * N) for radius: 1x buttons/inputs, 2x blog/images, 3x FAQ/TOC, 4x cards/containers
- Use weight 400 for body text, 500 for h3-h6/labels/nav, 600 for h1-h2/brand
- Use #FFFFFF backgrounds with #0F172A14 borders for elevated surfaces
- Use burgundy (#991B1B) for primary actions, links, and interactive accents
- Use filter: drop-shadow() for image/video/slideshow containers
- Preserve visual hierarchy and keep interaction states explicit

## Rules: Don't
- Don't use textures, patterns, or diagonal lines on backgrounds
- Don't use border-radius values other than 0.5rem, 0.75rem, 1rem, 1.5rem, or 2rem
- Don't use font weights other than 400, 500, or 600
- Don't use pill-shaped (9999px) border-radius on buttons or inputs
- Don't hard-code colors; reference --pico-* tokens (exception: #FFFFFF surfaces, #0F172A footer, shadow hex values)

## 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.