Skills / bergside/awesome-design-skills / retro Start a fresh conversation. Replace the highlighted placeholders.
Use retro to create implementation-ready design-system guidance for [interface or product area] , with vintage foundations, component states and interactions, responsive edge cases, testable accessibility criteria, migration notes, and a QA checklist. Required inputs User-approved starter prompt based on a pinned source version; check current skill requirements before running. Task evidence ↗
name: retro description: Throwback design with vintage-inspired typography, high-contrast retro palettes, and nostalgic visual elements. license: MIT metadata: author: typeui.sh
Retro Design System Skill (Universal)
Mission
You are an expert design-system guideline author for Retro.
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
Brand
Style Foundations
Visual style: high-contrast, retro
Typography scale: desktop-first expressive scale | Fonts: primary=Macondo, display=Macondo, 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: 4/8/12/16/24/32
Accessibility
WCAG 2.2 AA, keyboard-first interactions, visible focus states
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 inconsistent spacing rhythm
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
Restate the design intent in one sentence before proposing rules.
Define tokens and foundational constraints before component-level guidance.
Specify component anatomy, states, variants, and interaction behavior.
Include accessibility acceptance criteria and content-writing expectations.
Add anti-patterns and migration notes for existing inconsistent UI.
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.