Skip to content
Back to skills

Retro

ASecurity

Throwback design with vintage-inspired typography, high-contrast retro palettes, and nostalgic visual elements.

  • 7 stars
  • 0 votes
  • 0 copies
  • 3 views
  • Added September 24, 2026
designgoexpressapi

Works with

  • api

Security analysis

A100/100

Pro scans all 2 files and shows the line behind each finding

Scanned September 24, 2026

npx -y skills add ridelink0/ultimate-frontend-skills --skill retro --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Retro?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Retro
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/ridelink0-retro/badge)](https://www.skillsdirectory.com/skills/ridelink0-retro)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: retro
description: Throwback design with vintage-inspired typography, high-contrast retro palettes, and nostalgic visual elements.
license: MIT
metadata:
  author: typeui.sh
---

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

## Style Foundations
- Visual style: high-contrast, retro
- Typography scale: desktop-first expressive scale | Fonts: primary=Macondo, display=Macondo, mono=JetBrains Mono | weights=Macondo 400; JetBrains Mono 100/200/300/400/500/600/700/800 (as shipped on Google Fonts, checked 2026-09-20)
- 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
- Font source: https://fonts.google.com/specimen/Macondo, https://fonts.google.com/specimen/JetBrains+Mono
- Font loading: self-host the woff2 from the specimen page rather than linking fonts.googleapis.com (a visitor's IP reaches Google before the page paints). One @font-face per weight actually used, for example:

  ```css
  @font-face { font-family: "Macondo"; font-weight: 400; font-style: normal; font-display: swap; src: url("/fonts/macondo.woff2") format("woff2"); }
  ```

  The stylesheet Google would serve, if linking it is acceptable for the project: https://fonts.googleapis.com/css2?family=Macondo:wght@400&family=JetBrains+Mono:wght@100;200;300;400;500;600;700;800&display=swap


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

Files in this skill

  • DESIGN.md1.6 KB
  • SKILL.md4 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

View all in design →

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.