feat: IMAP mail sync with thread-to-contact matching (PRD §6.1)
Real IMAP connection via imapflow library: - Connects to IMAP server (IMAPFlow, TLS on port 993) - Fetches recent messages (configurable limit, default 20) - Extracts: from, fromEmail, subject, date, snippet (200 chars) - Thread-to-contact matching (PRD §6.1): 1. Match sender email against persons table 2. If no person match, extract domain and match against company.website 3. Returns matchedCompany + matchedPerson for each email - Audit-logged (action: crm.mailsync:imap) - Zod validated (host, port, user, password, folder, limit) - 502 on IMAP connection failure with detail - 400 on validation failure Tested: invalid creds → 502 'IMAP connection failed', missing host → 400
This commit is contained in:
Z User committed
1 parent
7acc0c5451
commit
e45b68bb8b
1089 files changed
+260614
No files matched your search
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Agentic
|
||||
colors:
|
||||
primary: "#FF5701"
|
||||
secondary: "#F6F6F1"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Playfair Display"
|
||||
fontSize: 2.5rem
|
||||
body-md:
|
||||
fontFamily: "Playfair Display"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.875rem
|
||||
sourceScale: "14/16/18/24/32/40"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 8px
|
||||
md: 16px
|
||||
sourceScale: "8pt baseline grid"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Conversational AI-first interface with minimal controls, clear outcomes, and delegated task flows for agentic workflows.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** modern, bold
|
||||
- **Typography scale:** 14/16/18/24/32/40
|
||||
- **Typography fonts:** primary=Playfair Display, display=Playfair Display, mono=JetBrains Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** surface/subtle layers
|
||||
- **Spacing scale:** 8pt baseline grid
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#FF5701):** Token from style foundations.
|
||||
- **Secondary (#F6F6F1):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,89 @@
|
||||
---
|
||||
name: agentic
|
||||
description: Conversational AI-first interface with minimal controls, clear outcomes, and delegated task flows for agentic workflows.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Agentic Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Agentic.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
The agentic design style emphasizes conversational interactions, clear outcomes, and minimal controls, allowing users to delegate tasks to AI instead of manually managing complex workflows.
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: modern, bold
|
||||
- Typography scale: 14/16/18/24/32/40 | Fonts: primary=Playfair Display, display=Playfair Display, mono=JetBrains Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: surface/subtle layers | Tokens: primary=#FF5701, secondary=#F6F6F1, 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, high-contrast support
|
||||
|
||||
## Writing Tone
|
||||
concise, confident, helpful, clear, friendly, professional, action-oriented, low-jargon
|
||||
|
||||
## Rules: Do
|
||||
- prefer semantic tokens over raw values
|
||||
- preserve visual hierarchy
|
||||
- keep interaction states explicit
|
||||
- design for empty/loading/error states
|
||||
- ensure responsive behavior by default
|
||||
- document accessibility rationale
|
||||
|
||||
## Rules: Don't
|
||||
- avoid low contrast text
|
||||
- avoid inconsistent spacing rhythm
|
||||
- avoid decorative motion without purpose
|
||||
- avoid ambiguous labels
|
||||
- avoid mixing multiple visual metaphors
|
||||
- avoid inaccessible hit areas
|
||||
|
||||
## 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 -->
|
||||
+55
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Ant
|
||||
colors:
|
||||
primary: "#1677ff"
|
||||
secondary: "#8B5CF6"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Plus Jakarta Sans"
|
||||
fontSize: 2rem
|
||||
body-md:
|
||||
fontFamily: "Plus Jakarta Sans"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "12/14/16/20/24/32"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Structured, enterprise-focused design system emphasizing clarity, consistency, and efficiency for data-dense web applications.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** data-dense, enterprise
|
||||
- **Typography scale:** 12/14/16/20/24/32
|
||||
- **Typography fonts:** primary=Plus Jakarta Sans, display=Plus Jakarta Sans, mono=JetBrains Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#1677ff):** Token from style foundations.
|
||||
- **Secondary (#8B5CF6):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
+89
@@ -0,0 +1,89 @@
|
||||
---
|
||||
name: ant
|
||||
description: Structured, enterprise-focused design system emphasizing clarity, consistency, and efficiency for data-dense web applications.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Ant Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Ant.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
Ant Design follows a structured, enterprise-focused design system that emphasizes clarity, consistency, and efficiency in complex web applications.
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: data-dense, enterprise
|
||||
- Typography scale: 12/14/16/20/24/32 | Fonts: primary=Plus Jakarta Sans, display=Plus Jakarta Sans, mono=JetBrains Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary, neutral, success, warning, danger | Tokens: primary=#1677ff, 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, clear, friendly, professional, action-oriented, low-jargon
|
||||
|
||||
## Rules: Do
|
||||
- prefer semantic tokens over raw values
|
||||
- preserve visual hierarchy
|
||||
- keep interaction states explicit
|
||||
- design for empty/loading/error states
|
||||
- ensure responsive behavior by default
|
||||
- document accessibility rationale
|
||||
|
||||
## Rules: Don't
|
||||
- avoid low contrast text
|
||||
- avoid inconsistent spacing rhythm
|
||||
- avoid decorative motion without purpose
|
||||
- avoid ambiguous labels
|
||||
- avoid mixing multiple visual metaphors
|
||||
- avoid inaccessible hit areas
|
||||
|
||||
## 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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Application
|
||||
colors:
|
||||
primary: "#9333ea"
|
||||
secondary: "#a855f7"
|
||||
success: "#10b981"
|
||||
warning: "#f59e0b"
|
||||
danger: "#ef4444"
|
||||
surface: "#FFFFFF"
|
||||
text: "#09090b"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Inter"
|
||||
fontSize: 2rem
|
||||
body-md:
|
||||
fontFamily: "Inter"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "12/14/16/20/24/32"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
App dashboard with purple-themed aesthetic, top-bar navigation, card-based layouts, and developer-first workflows.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** modern, clean, high-contrast, glass-like panels, soft shadows, rounded components
|
||||
- **Typography scale:** 12/14/16/20/24/32
|
||||
- **Typography fonts:** primary=Inter, display=Inter, mono=JetBrains Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary (purple), neutral, success, warning, danger
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#9333ea):** Token from style foundations.
|
||||
- **Secondary (#a855f7):** Token from style foundations.
|
||||
- **Success (#10b981):** Token from style foundations.
|
||||
- **Warning (#f59e0b):** Token from style foundations.
|
||||
- **Danger (#ef4444):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#09090b):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,84 @@
|
||||
---
|
||||
name: application
|
||||
description: App dashboard with purple-themed aesthetic, top-bar navigation, card-based layouts, and developer-first workflows.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Application Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Application.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
A modern, Vercel/GitHub-inspired application dashboard designed for clarity, speed, and developer-first workflows. The interface focuses on simplicity and visual hierarchy, allowing teams to monitor, deploy, and manage applications effortlessly from a single control center. Features a top-bar only navigation (no sidebar) and a clean purple-themed aesthetic.
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: modern, clean, high-contrast, glass-like panels, soft shadows, rounded components
|
||||
- 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 (purple), neutral, success, warning, danger | Tokens: primary=#9333ea, secondary=#a855f7, success=#10b981, warning=#f59e0b, danger=#ef4444, surface=#FFFFFF, text=#09090b
|
||||
- Layout: Top-bar only navigation, structured grid layout, card-based content
|
||||
- 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
|
||||
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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Artistic
|
||||
colors:
|
||||
primary: "#3B82F6"
|
||||
secondary: "#8B5CF6"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Limelight"
|
||||
fontSize: 2.25rem
|
||||
body-md:
|
||||
fontFamily: "Limelight"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "12/14/16/18/24/30/36"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
High-contrast, expressive style with creative typography and bold color choices for visually striking interfaces.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** high-contrast, artistic
|
||||
- **Typography scale:** 12/14/16/18/24/30/36
|
||||
- **Typography fonts:** primary=Limelight, display=Limelight, mono=JetBrains Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#3B82F6):** Token from style foundations.
|
||||
- **Secondary (#8B5CF6):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,89 @@
|
||||
---
|
||||
name: artistic
|
||||
description: High-contrast, expressive style with creative typography and bold color choices for visually striking interfaces.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Artistic Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Artistic.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: high-contrast, artistic
|
||||
- Typography scale: 12/14/16/18/24/30/36 | Fonts: primary=Limelight, display=Limelight, 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, semantic HTML before ARIA, screen-reader tested labels, reduced-motion support, 44px+ touch targets, high-contrast support
|
||||
|
||||
## Writing Tone
|
||||
concise, confident, professional, action-oriented
|
||||
|
||||
## Rules: Do
|
||||
- prefer semantic tokens over raw values
|
||||
- preserve visual hierarchy
|
||||
- keep interaction states explicit
|
||||
- design for empty/loading/error states
|
||||
- ensure responsive behavior by default
|
||||
- document accessibility rationale
|
||||
|
||||
## Rules: Don't
|
||||
- avoid low contrast text
|
||||
- avoid inconsistent spacing rhythm
|
||||
- avoid decorative motion without purpose
|
||||
- avoid ambiguous labels
|
||||
- avoid mixing multiple visual metaphors
|
||||
- avoid inaccessible hit areas
|
||||
|
||||
## 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 -->
|
||||
@@ -0,0 +1,315 @@
|
||||
# Atelier Zero
|
||||
|
||||
> Category: Editorial · Studio
|
||||
> A magazine-grade, collage-driven visual system: warm paper canvas, surreal
|
||||
> plaster-and-architecture imagery, oversized display type, hairline rules,
|
||||
> Roman-numeral section markers, and tiny editorial annotations.
|
||||
> Inspired by the production values of high-end print magazines (Monocle,
|
||||
> Apartamento, IDEA) translated into a working website.
|
||||
|
||||
## 1. Visual Theme & Atmosphere
|
||||
|
||||
A small, high-craft studio's annual report rendered as a webpage. The
|
||||
canvas is warm handmade paper. Every surface earns its lines. Type does
|
||||
the heavy lifting; collage imagery does the storytelling. Coral provides
|
||||
the only spark of warmth; mustard, olive, and bone are quiet
|
||||
companions. The page feels printed, slightly aged, and intentionally
|
||||
restrained — never noisy, never neon.
|
||||
|
||||
- **Visual style:** editorial, collage, museum-catalog calm.
|
||||
- **Posture:** asymmetric, generous, top-biased.
|
||||
- **Reading rhythm:** Roman numerals (I, II, III…) walk the reader
|
||||
through the page like chapters in a printed essay.
|
||||
- **Mood:** intelligent, tactile, slightly poetic, unmistakably
|
||||
international.
|
||||
|
||||
### Print production references
|
||||
|
||||
The three magazines are not interchangeable inspiration — each owns a
|
||||
specific dimension of the system. When a brief asks "shift it closer to
|
||||
X", consult this map before changing tokens:
|
||||
|
||||
- **Monocle:** warm paper stock (`#efe7d2`), tight body leading (~1.55),
|
||||
monospace coordinates and SHA stamps, the international metadata
|
||||
strip ("Filed under …"), the small ★ in the nav.
|
||||
- **Apartamento:** surreal collage composition (plaster + architecture
|
||||
+ small human figure), torn-edge textures inside the imagery, the
|
||||
rotated side notes, and the willingness to leave generous negative
|
||||
space around an image.
|
||||
- **IDEA:** Roman-numeral section walks (I → VIII), oversized
|
||||
italic-serif words mixed inline with bold sans (Playfair Italic 500
|
||||
inside Inter Tight 800), hairline rules threading through method
|
||||
steps, the closing mega-word footer.
|
||||
|
||||
## 2. Color
|
||||
|
||||
All values are tokens. Do not invent new hex.
|
||||
|
||||
- **Paper:** `#efe7d2` — primary background, warm ivory.
|
||||
- **Paper-warm:** `#ece4cf` — second-tier surface tint.
|
||||
- **Paper-dark:** `#ddd2b6` — subtle wells, cards on cards.
|
||||
- **Bone:** `#f7f1de` — elevated card surface (always on Paper).
|
||||
- **Ink:** `#15140f` — body text, primary buttons, strong rules.
|
||||
- **Ink-soft:** `#2a2620` — secondary text, dense paragraphs.
|
||||
- **Ink-mute:** `#5a5448` — captions, lab descriptions.
|
||||
- **Ink-faint:** `#8b8676` — coordinates, page numbers, microcopy.
|
||||
- **Coral (accent):** `#ed6f5c` — single hot accent. CTA fills,
|
||||
Roman-numeral marks, eyebrow underlines, pulse dots, "fin." marks.
|
||||
- **Coral-soft:** `#f08e7c` — hover/secondary coral states only.
|
||||
- **Mustard:** `#e9b94a` — used sparingly: a single ★ in the nav, a
|
||||
highlighted ring in stats, occasional dot on a numbered annotation.
|
||||
- **Olive:** `#6e7448` — quiet third accent for tags or partner glyphs.
|
||||
|
||||
### Color rules
|
||||
|
||||
- One **coral** moment per ~600vh. If two CTAs are coral, the
|
||||
Roman numerals should be ink-faint instead.
|
||||
- Mustard is never used for a CTA. It is jewelry.
|
||||
- Pure white (`#fff`) only inside the dark "selected work" panel as
|
||||
inverse text. Never on Paper.
|
||||
- Pure black is forbidden. The darkest value is `Ink #15140f`.
|
||||
|
||||
### Why single-accent (not multi-accent)
|
||||
|
||||
Multi-accent editorial systems (e.g. *The New Yorker* using red for
|
||||
Opinion and teal for Culture) work when the publication has stable
|
||||
content categories and a long-term reader who learns the code. A
|
||||
single-shot studio landing page does not have that runway. One coral
|
||||
moment per ~600vh forces the agent to pick the single most important
|
||||
beat per viewport instead of balancing two chromatic hierarchies, and
|
||||
keeps the page calibrated to the warm-paper canvas. Mustard and olive
|
||||
exist as **jewelry** (≤1% surface area: a star, a dot, a partner glyph)
|
||||
— never as semantic signals, and never as CTA fills.
|
||||
|
||||
### Surface noise
|
||||
|
||||
Every page MUST overlay a faint paper noise texture using a fixed,
|
||||
pointer-events-disabled `::before` pseudo-element with a
|
||||
multiply-blend SVG turbulence at ~5–7% opacity, plus two soft
|
||||
radial gradients in `rgba(106, 92, 56, 0.06)` to simulate
|
||||
hand-pressed paper warmth.
|
||||
|
||||
## 3. Typography
|
||||
|
||||
### Families
|
||||
|
||||
- **Display / sans:** `Inter Tight` 700–900 weights — headlines, section
|
||||
titles, button text. Letter-spacing `-0.025em` to `-0.04em` at
|
||||
display sizes.
|
||||
- **Italic emphasis / serif:** `Playfair Display` Italic, weight 500.
|
||||
Used inline inside display headlines on emphasized nouns, on Roman
|
||||
numerals, on testimonial quotes, on the brand mark `Ø`.
|
||||
- **Body:** `Inter` 300–500 — paragraph copy, lab descriptions.
|
||||
- **Mono:** `JetBrains Mono` 400–500 — code spans, coordinates,
|
||||
SHAs, plate numbers ("FIG. 01 / OD-26").
|
||||
|
||||
### Scale (px)
|
||||
|
||||
`9.5 · 10.5 · 11 · 13 · 14 · 16 · 17 · 22 · 26 · 38 · 54 · 66 · 78 · 90 · 200`
|
||||
|
||||
### Headline construction
|
||||
|
||||
Display headlines mix **bold sans** and **italic serif** in the same
|
||||
line. The serif italic carries the emotional words; the sans carries
|
||||
the structure. End every section H1/H2 with a coral period — `<span
|
||||
class="dot">.</span>`.
|
||||
|
||||
```
|
||||
Designing intelligence with skills, taste, and code.
|
||||
^^^^^^^^^ ^^^^^^^^ ^^^^^ ^^^^
|
||||
sans bold serif italic coral dot
|
||||
```
|
||||
|
||||
### Microcopy
|
||||
|
||||
- **Eyebrow / label:** 11px Inter Tight 600, `letter-spacing: 0.22em`,
|
||||
uppercase, coral, prefixed with an 18px coral hairline.
|
||||
- **Coordinates:** 10px JetBrains Mono, `letter-spacing: 0.04em`,
|
||||
ink-faint, e.g. `52.5200° N · 13.4050° E`.
|
||||
- **Page-of-pages:** `004 / 008` in Inter Tight 11px ink-faint.
|
||||
- **Roman numerals:** Playfair Italic 14px, coral, `I.` `II.` `III.` etc.
|
||||
at the head of every section rule.
|
||||
|
||||
## 4. Spacing & Grid
|
||||
|
||||
- **Container:** max-width `1360px`, side padding `64px` desktop,
|
||||
`44px` at ≤1280, `32px` at ≤1080, `24px` at ≤880.
|
||||
- **Section padding:** `130px` top+bottom desktop, `90px` for
|
||||
tight sections, `80px` ≤560.
|
||||
- **Grid:** 12-column conceptual, executed as CSS Grid with
|
||||
task-specific column ratios. Hero is `0.78fr 1.22fr`.
|
||||
- **Vertical rhythm:** 8px baseline. Allow 32–48px between
|
||||
paragraph blocks.
|
||||
- **Side rails:** Two 36px-wide fixed vertical strips on the left and
|
||||
right edges of the viewport, each containing a single rotated
|
||||
text label in 10px Inter Tight 600 letter-spaced 0.42em.
|
||||
|
||||
## 5. Layout & Composition
|
||||
|
||||
- **Top metadata strip** is mandatory: a single horizontal bar above
|
||||
the nav containing the volume/issue, a "Filed under …" badge, and a
|
||||
live-status pulse with version + locale. Inter Tight 10.5px,
|
||||
ink-faint, 1px ink-line border-bottom.
|
||||
- **Section rule** is mandatory at the top of every section:
|
||||
`[Roman.] · [meta middle] · [page-of-008]`.
|
||||
- **Image annotations**: every featured image carries 4 corner
|
||||
brackets (1px hairlines, 22×22), at least 1 plate number
|
||||
("Plate Nº 08"), and a coordinate or SHA.
|
||||
- **Hero must extend above the fold** at 1440×900 minimum. The image
|
||||
fills the viewport vertically (`calc(100vh - 160px)`), aligned to
|
||||
the right edge.
|
||||
- **Method sections** must use a 4-step layout with a horizontal
|
||||
hairline running through the step heads at the same Y, with
|
||||
`→` separators between titles.
|
||||
|
||||
## 6. Components
|
||||
|
||||
### Buttons
|
||||
|
||||
- **Primary:** coral fill `#ed6f5c`, white label, `999px` radius,
|
||||
`14px 22px` padding, with a white arrow `↗` SVG at 14px and a
|
||||
coral 0,14,26,-16 rgba shadow.
|
||||
- **Ghost:** transparent, `1px solid rgba(21,20,15,0.2)` border,
|
||||
ink label, same radius and padding.
|
||||
|
||||
### Cards
|
||||
|
||||
- **Bone-fill cards** (`#f7f1de`), 18px radius, 28×26 padding,
|
||||
inset 1px ink-at-6% ring + 30/60/-30/15 ambient shadow.
|
||||
- Each card has a `01–04` italic serif num plus a tag eyebrow on
|
||||
the same row.
|
||||
- A bottom-right 28px circular arrow mark turns coral on hover.
|
||||
|
||||
### Pill filters
|
||||
|
||||
- 10×18 padding, 999px, `1px solid line` border, transparent.
|
||||
- Active state: coral fill, white label, count separator opacity 0.7.
|
||||
|
||||
### Stat rings
|
||||
|
||||
- 32–34px circular dashed rings carrying a 2-digit number; one ring
|
||||
per row may be coral-stroked to denote the highlighted stat.
|
||||
|
||||
### Page numbers / index card
|
||||
|
||||
- Hero artwork carries a small bordered card on the right edge with
|
||||
`01–04` index entries. The current entry uses bold ink; the rest
|
||||
ink-faint. Each item prefixes the digit with a coral `01` token.
|
||||
|
||||
### Side rails
|
||||
|
||||
- Fixed 36px vertical strips at left + right edges, hidden below
|
||||
1280px. Each contains rotated 10px Inter Tight uppercase text
|
||||
letter-spaced 0.42em, never wraps.
|
||||
|
||||
### Roman section rules
|
||||
|
||||
Every section opens with a `.sec-rule`: top hairline 1px, then a
|
||||
flex row containing `[Roman]`, a centered metadata cluster, and
|
||||
the page-of-008 counter on the right.
|
||||
|
||||
## 7. Motion & Interaction
|
||||
|
||||
- **Pulse dot:** 6×6 coral circle at top metadata bar and footer,
|
||||
`pulse 2.4s ease-in-out infinite` between 1.0 and 0.35 opacity.
|
||||
- **Card hover:** translateY(-3px), arrow mark fills coral.
|
||||
- **Button hover:** translateY(-1px), darker coral fill.
|
||||
- **Pill hover:** ink-at-4% wash.
|
||||
- **Transitions:** `0.18s ease` everywhere; never longer than `0.25s`.
|
||||
- **No parallax, no scroll-jacking, no auto-rotators.** Editorial
|
||||
pages do not animate themselves at the user.
|
||||
|
||||
## 8. Voice & Brand
|
||||
|
||||
- Headlines mix declarative and italicized emotional words.
|
||||
- Body copy is plain-spoken and specific. Quote real numbers
|
||||
(12 / 31 / 72), real coordinates (52.5200° N · 13.4050° E),
|
||||
real commands (`pnpm tools-dev`).
|
||||
- Microcopy uses publication metaphors: "Filed under", "Plate Nº",
|
||||
"Vol. 01 / Issue Nº 26", "FIN.", "MMXXVI", "Edited by".
|
||||
- Latin numerals — Roman for sections, Arabic for stats.
|
||||
|
||||
## 9. Anti-patterns
|
||||
|
||||
- ❌ No drop shadows above 30px blur. No gradients on text.
|
||||
- ❌ No emoji in product copy. ★ is allowed once in the nav CTA.
|
||||
- ❌ No glassmorphism, no neon, no neumorphism, no rounded
|
||||
corners larger than 24px (except 32px on the dark "Selected Work" panel).
|
||||
- ❌ No more than one coral CTA per viewport.
|
||||
- ❌ No collage image without corner brackets and at least one
|
||||
monospace annotation.
|
||||
- ❌ No Roman numeral skipped — sections must be sequential.
|
||||
- ❌ No pure white, no pure black, no pure 100%-saturation accent.
|
||||
|
||||
### Anti-patterns specific to AI-generated imagery
|
||||
|
||||
This system is paired with `gpt-image-fal` / `gpt-image-azure` via the
|
||||
open-design-landing skill. Several common image-model defaults will
|
||||
silently break the Atelier Zero aesthetic, so they are forbidden in
|
||||
every collage prompt and rejected on visual review:
|
||||
|
||||
- ❌ No lens flares, light leaks, bloom, or cinematic post-FX. The
|
||||
paper-and-museum mood is matte, not cinematic.
|
||||
- ❌ No glitch, datamosh, RGB-split, or scanline artifacts.
|
||||
- ❌ No photorealistic human faces or stock-portrait people. Plaster
|
||||
fragments, busts, and small scale figures only — eyes never look at
|
||||
the viewer.
|
||||
- ❌ No visible AI signatures, watermarks, generator logos, or
|
||||
hallucinated model captions. The rendered surface must read as a
|
||||
printed page, not a model output.
|
||||
- ❌ No DSLR-style shallow depth-of-field bokeh on the collage
|
||||
fragments — every plane stays in focus.
|
||||
|
||||
## 10. Responsive Behavior
|
||||
|
||||
- **Desktop ≥ 1280px:** full container, two side rails visible,
|
||||
metadata strip shows all three columns.
|
||||
- **Laptop 1080–1279px:** side rails hidden, container 32–44px
|
||||
padding, metadata strip's middle column collapses.
|
||||
- **Tablet 880–1079px:** hero / about / capabilities / testimonial
|
||||
/ cta grids collapse to 1 column at 50px gap. Method becomes 2×2,
|
||||
the connecting hairline is removed. Nav links + brand-meta hide;
|
||||
brand-mark + CTA remain.
|
||||
- **Phone < 560px:** all multi-column grids become 1 col;
|
||||
section padding drops to 80px.
|
||||
|
||||
## 11. Imagery
|
||||
|
||||
This system is collage-first. Every page-level image must be
|
||||
generated to match these constraints:
|
||||
|
||||
- **Background:** warm ivory paper with subtle grain, faint vertical
|
||||
folds, drafting registration marks.
|
||||
- **Subject:** classical plaster head fragments, brutalist concrete
|
||||
blocks, archways, stairs, tree, sky cutouts, one small human figure.
|
||||
- **Color overlay:** restrained — cream, stone, charcoal, washed
|
||||
coral, occasional mustard, pale-blue inside small sky cutouts.
|
||||
- **Annotations baked in:** thin hairline circles, crosshairs,
|
||||
dotted matrices, numbered tags. Never typography that conflicts
|
||||
with on-page copy.
|
||||
|
||||
For imagery, use a consistent working prompt pack with per-section variants. All renders should be
|
||||
at 16:9 (heroes) or 1:1 (cards / about / cta), saved as PNG, ≥1024px
|
||||
on the long edge.
|
||||
|
||||
## 12. Agent Prompt Guide
|
||||
|
||||
When generating against this design system:
|
||||
|
||||
- The page is a **printed magazine** that happens to deploy. Lean
|
||||
into print metaphors before web metaphors.
|
||||
- Always include the metadata strip, the side rails, the Roman
|
||||
section rules, and a footer with a giant `Open Design.` (or brand)
|
||||
word at clamp(70px, 13vw, 200px).
|
||||
- Coral is a single character on stage. If you find yourself
|
||||
reaching for a second coral element in the same viewport, use
|
||||
ink-faint or mustard instead.
|
||||
- Italic serif words inside display headlines should always be
|
||||
emotional nouns: *intelligence*, *taste*, *memorable*, *open*,
|
||||
*visually*. Never verbs, never adjectives.
|
||||
- If asked for "more dramatic," the lever is **typography size**
|
||||
(clamp top to 90–110px) and **image height** (push to 100vh - nav).
|
||||
Do not reach for color.
|
||||
- If asked for "more minimal," remove decorative side notes and
|
||||
reduce annotations to one per image — never remove the Roman
|
||||
rules or the metadata strip.
|
||||
@@ -0,0 +1,85 @@
|
||||
---
|
||||
name: atelier-zero
|
||||
description: Magazine-grade, collage-driven editorial system: warm paper canvas, surreal plaster-and-architecture imagery, oversized display type, hairline rules, and Roman-numeral section markers.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: hand-authored
|
||||
---
|
||||
|
||||
<!-- HAND_AUTHORED_MANAGED_START -->
|
||||
# Atelier Zero Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Atelier Zero.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers. This system is hand-authored; treat its DESIGN.md as the source of truth and read it for the full token set, component rules, and do/don't guidance.
|
||||
|
||||
## Brand
|
||||
Atelier Zero — intelligent, tactile, slightly poetic, international.
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: editorial, collage, museum-catalog calm
|
||||
- Typography fonts: primary=Playfair Display, display=Playfair Display, mono=monospace
|
||||
- Color palette: coral, mustard, olive, bone, paper
|
||||
- Key tokens: paper=#efe7d2, coral=#e8633f, mustard=#c89a3c, olive=#6b6f4a, ink=#1a1a16
|
||||
- Spacing / layout: generous editorial rhythm, asymmetric top-biased
|
||||
|
||||
## Accessibility
|
||||
WCAG 2.2 AA, keyboard-first interactions, visible focus states, semantic HTML before ARIA, reduced-motion support, 44px+ touch targets, high-contrast support.
|
||||
|
||||
## Writing Tone
|
||||
intelligent, tactile, slightly poetic, international
|
||||
|
||||
## Rules: Do
|
||||
- prefer semantic tokens over raw values
|
||||
- preserve visual hierarchy
|
||||
- keep interaction states explicit
|
||||
- read DESIGN.md for the authoritative palette, type, and component rules
|
||||
|
||||
## Rules: Don't
|
||||
- avoid low contrast text
|
||||
- avoid inconsistent spacing rhythm
|
||||
- avoid ambiguous labels
|
||||
- do not invent hex values outside this system's palette
|
||||
|
||||
## 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.
|
||||
|
||||
<!-- HAND_AUTHORED_MANAGED_END -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Bento
|
||||
colors:
|
||||
primary: "#FAD4C0"
|
||||
secondary: "#80A1C1"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFF5E6"
|
||||
text: "#111827"
|
||||
neutral: "#FFF5E6"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Inter"
|
||||
fontSize: 2rem
|
||||
body-md:
|
||||
fontFamily: "Inter"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "12/14/16/20/24/32"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Modular grid layout with card-like blocks, clear hierarchy, soft spacing, and subtle visual contrast for organized, scannable interfaces.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** modern, clean
|
||||
- **Typography scale:** 12/14/16/20/24/32
|
||||
- **Typography fonts:** primary=Inter, display=Inter, mono=JetBrains Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#FAD4C0):** Token from style foundations.
|
||||
- **Secondary (#80A1C1):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFF5E6):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFF5E6):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
name: bento
|
||||
description: Modular grid layout with card-like blocks, clear hierarchy, soft spacing, and subtle visual contrast for organized, scannable interfaces.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Bento Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Bento.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
The bento box style is an innovative design approach that uses a grid layout to present content in visually appealing blocks of varying sizes.
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: modern, clean
|
||||
- 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=#FAD4C0, secondary=#80A1C1, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#FFF5E6, 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
|
||||
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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Bold
|
||||
colors:
|
||||
primary: "#0077BC"
|
||||
secondary: "#009866"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#111111"
|
||||
text: "#111827"
|
||||
neutral: "#111111"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Archivo Black"
|
||||
fontSize: 3rem
|
||||
body-md:
|
||||
fontFamily: "Archivo Black"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "desktop-first expressive scale"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Strong visual presence with heavyweight typography, high-contrast colors, and commanding layouts.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** bold
|
||||
- **Typography scale:** desktop-first expressive scale
|
||||
- **Typography fonts:** primary=Archivo Black, display=Archivo Black, mono=JetBrains Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, secondary
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#0077BC):** Token from style foundations.
|
||||
- **Secondary (#009866):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#111111):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#111111):** Derived from the surface token for official format compatibility.
|
||||
+83
@@ -0,0 +1,83 @@
|
||||
---
|
||||
name: bold
|
||||
description: Strong visual presence with heavyweight typography, high-contrast colors, and commanding layouts.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Bold Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Bold.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: bold
|
||||
- Typography scale: desktop-first expressive scale | Fonts: primary=Archivo Black, display=Archivo Black, mono=JetBrains Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary, secondary | Tokens: primary=#0077BC, secondary=#009866, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#111111, text=#111827
|
||||
- Spacing scale: 4/8/12/16/24/32
|
||||
|
||||
|
||||
## Accessibility
|
||||
WCAG 2.2 AA, keyboard-first interactions, visible focus states, screen-reader tested labels, reduced-motion support, 44px+ touch targets, high-contrast support
|
||||
|
||||
## Writing Tone
|
||||
friendly, professional
|
||||
|
||||
## 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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Brutalism
|
||||
colors:
|
||||
primary: "#DD614C"
|
||||
secondary: "#DAA144"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Darker Grotesque"
|
||||
fontSize: 3rem
|
||||
body-md:
|
||||
fontFamily: "Darker Grotesque"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "desktop-first expressive scale"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Raw, anti-design aesthetic inspired by concrete architecture with unadorned elements, jarring layouts, and functional minimalism.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** bold
|
||||
- **Typography scale:** desktop-first expressive scale
|
||||
- **Typography fonts:** primary=Darker Grotesque, display=Darker Grotesque, mono=JetBrains Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, secondary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#DD614C):** Token from style foundations.
|
||||
- **Secondary (#DAA144):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,97 @@
|
||||
---
|
||||
name: brutalism
|
||||
description: Raw, anti-design aesthetic inspired by concrete architecture with unadorned elements, jarring layouts, and functional minimalism.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Brutalism Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
|
||||
You are an expert design-system guideline author for Brutalism.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
|
||||
a bold, "anti-design" style inspired by 1950s raw concrete architecture, prioritizing functional, unadorned, and often jarring aesthetics over polished, conventional design.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- Visual style: bold
|
||||
- Typography scale: desktop-first expressive scale | Fonts: primary=Darker Grotesque, display=Darker Grotesque, mono=JetBrains Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary, secondary, neutral, success, warning, danger | Tokens: primary=#DD614C, secondary=#DAA144, 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
|
||||
|
||||
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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Cafe
|
||||
colors:
|
||||
primary: "#5D4432"
|
||||
secondary: "#E9E3DD"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#F9F7F5"
|
||||
text: "#3E2B1E"
|
||||
neutral: "#F9F7F5"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Poppins"
|
||||
fontSize: 3rem
|
||||
body-md:
|
||||
fontFamily: "Poppins"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "desktop-first expressive scale"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 2px
|
||||
md: 4px
|
||||
sourceScale: "2/4/8/12/16/24/32/48"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Cozy cafe-inspired interface with warm tones, soft typography, and clean layouts for a relaxed browsing experience.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** minimal, clean
|
||||
- **Typography scale:** desktop-first expressive scale
|
||||
- **Typography fonts:** primary=Poppins, display=Poppins, mono=JetBrains Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 2/4/8/12/16/24/32/48
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#5D4432):** Token from style foundations.
|
||||
- **Secondary (#E9E3DD):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#F9F7F5):** Token from style foundations.
|
||||
- **Text (#3E2B1E):** Token from style foundations.
|
||||
- **Neutral (#F9F7F5):** Derived from the surface token for official format compatibility.
|
||||
+83
@@ -0,0 +1,83 @@
|
||||
---
|
||||
name: cafe
|
||||
description: Cozy cafe-inspired interface with warm tones, soft typography, and clean layouts for a relaxed browsing experience.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Cafe Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Cafe.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
A cozy café-inspired interface that blends warm tones, soft typography, and clean layouts to create a relaxed browsing experience
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: minimal, clean
|
||||
- Typography scale: desktop-first expressive scale | Fonts: primary=Poppins, display=Poppins, mono=JetBrains Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary, neutral, success, warning, danger | Tokens: primary=#5D4432, secondary=#E9E3DD, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#F9F7F5, text=#3E2B1E
|
||||
- Spacing scale: 2/4/8/12/16/24/32/48
|
||||
|
||||
|
||||
## 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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Claude
|
||||
colors:
|
||||
primary: "#141413"
|
||||
secondary: "#FAF9F6"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Anthropic Sans"
|
||||
fontSize: 2rem
|
||||
body-md:
|
||||
fontFamily: "Anthropic Sans"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "12/14/16/20/24/32"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Research-journal aesthetic on warm stone with near-black ink, restrained earthy accents, and editorially strict contrast.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** modern, minimal, clean
|
||||
- **Typography scale:** 12/14/16/20/24/32
|
||||
- **Typography fonts:** primary=Anthropic Sans, display=Anthropic Sans, mono=JetBrains Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, secondary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#141413):** Token from style foundations.
|
||||
- **Secondary (#FAF9F6):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,81 @@
|
||||
---
|
||||
name: "claude"
|
||||
description: "A research-journal aesthetic printed on warm stone — authoritative, editorial, almost achromatic. Pages live on warm ivory parchment (never pure white), with near-black slate as the dominant ink."
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Claude Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Claude.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
A research-journal aesthetic printed on warm stone — authoritative, editorial, almost achromatic. Pages live on warm ivory parchment (never pure white), with near-black slate as the dominant ink. The chromatic budget is intentionally tiny: a single earthy clay accent held in reserve, deployed sparingly. Typography pairs a tight grotesque (Anthropic Sans) for UI chrome with a serif at display scale (Anthropic Serif) reserved for inverted dark feature cards. Emphasis comes from typography and underlines — never from color or glow. Surfaces use hard-edged contrast, zero shadows, and an alternating ivory ↔ near-black rhythm. Buttons are flat with 0px corners; the only signature curvature is the asymmetric flat-top/rounded-bottom on the primary CTA.
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: modern, minimal, clean
|
||||
- Typography scale: 12/14/16/20/24/32 | Fonts: primary=Anthropic Sans, display=Anthropic Sans, mono=JetBrains Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary, secondary, neutral, success, warning, danger | Tokens: primary=#141413, secondary=#FAF9F6, 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
|
||||
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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Claymorphism
|
||||
colors:
|
||||
primary: "#3B82F6"
|
||||
secondary: "#FFFFFF"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#1C398E"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Poppins"
|
||||
fontSize: 3rem
|
||||
body-md:
|
||||
fontFamily: "Montserrat"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "desktop-first expressive scale"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Soft, rounded 3D-like shapes mimicking malleable clay with playful, puffy elements and colorful surfaces.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** modern, high-contrast, playful
|
||||
- **Typography scale:** desktop-first expressive scale
|
||||
- **Typography fonts:** primary=Montserrat, display=Poppins, mono=JetBrains Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#3B82F6):** Token from style foundations.
|
||||
- **Secondary (#FFFFFF):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#1C398E):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,84 @@
|
||||
---
|
||||
name: claymorphism
|
||||
description: Soft, rounded 3D-like shapes mimicking malleable clay with playful, puffy elements and colorful surfaces.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# claymorphism Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for claymorphism.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
a modern UI trend characterized by soft, rounded, 3D-like, "puffy" shapes that mimic malleable, colorful clay.
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: modern, high-contrast, playful
|
||||
- Typography scale: desktop-first expressive scale | Fonts: primary=Montserrat, display=Poppins, mono=JetBrains Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary, neutral, success, warning, danger | Tokens: primary=#3B82F6, secondary=#FFFFFF, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#FFFFFF, text=#1C398E
|
||||
- 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
|
||||
- avoid mixing multiple visual metaphors
|
||||
|
||||
## 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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Clean
|
||||
colors:
|
||||
primary: "#3B82F6"
|
||||
secondary: "#8B5CF6"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Poppins"
|
||||
fontSize: 2rem
|
||||
body-md:
|
||||
fontFamily: "Roboto"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "Inconsolata"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "12/14/16/20/24/32"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 8px
|
||||
md: 16px
|
||||
sourceScale: "8pt baseline grid"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Simplicity-focused design with ample whitespace, legible typography, and a limited color palette to reduce visual clutter.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** minimal, clean
|
||||
- **Typography scale:** 12/14/16/20/24/32
|
||||
- **Typography fonts:** primary=Roboto, display=Poppins, mono=Inconsolata
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 8pt baseline grid
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#3B82F6):** Token from style foundations.
|
||||
- **Secondary (#8B5CF6):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,84 @@
|
||||
---
|
||||
name: clean
|
||||
description: Simplicity-focused design with ample whitespace, legible typography, and a limited color palette to reduce visual clutter.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Clean Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Clean.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
Clean design style focuses on simplicity, minimalism, and high usability, using ample whitespace, legible typography, and limited color palettes to reduce visual clutter
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: minimal, clean
|
||||
- Typography scale: 12/14/16/20/24/32 | Fonts: primary=Roboto, display=Poppins, mono=Inconsolata | 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
|
||||
clear, friendly
|
||||
|
||||
## Rules: Do
|
||||
- prefer semantic tokens over raw values
|
||||
- keep interaction states explicit
|
||||
- design for empty/loading/error states
|
||||
|
||||
## Rules: Don't
|
||||
- avoid low contrast text
|
||||
- avoid inconsistent spacing rhythm
|
||||
- avoid decorative motion without purpose
|
||||
- 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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Codex
|
||||
colors:
|
||||
primary: "#000000"
|
||||
secondary: "#FFFFFF"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Open Sans"
|
||||
fontSize: 2rem
|
||||
body-md:
|
||||
fontFamily: "Open Sans"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "12/14/16/20/24/32"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Radically minimal blank-canvas interface where black carries structure and typography drives hierarchy.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** modern, minimal, clean
|
||||
- **Typography scale:** 12/14/16/20/24/32
|
||||
- **Typography fonts:** primary=Open Sans, display=Open Sans, mono=JetBrains Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, secondary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#000000):** Token from style foundations.
|
||||
- **Secondary (#FFFFFF):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,81 @@
|
||||
---
|
||||
name: "codex"
|
||||
description: "A radically minimal, blank-canvas interface built as a pure edge-to-edge surface, with almost no color and typography carrying the visual weight. Black serves as the only filled color, the only divider, and the sole surface tone cards."
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Open Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Codex.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
A radically minimal, blank-canvas interface built as a pure edge-to-edge surface, with almost no color and typography carrying the visual weight. Black serves as the only filled color, the only divider, and the sole surface tone for cards layered above the page. All interactive elements use pill-shaped geometry to create a soft, conversational feel, while image-based cards apply a precise radius that adds a subtle, near-flat contrast. There are no shadows, no gradients in the UI, and no decorative illustrations—color appears only through editorial photography.
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: modern, minimal, clean
|
||||
- Typography scale: 12/14/16/20/24/32 | Fonts: primary=Open Sans, display=Open Sans, mono=JetBrains Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary, secondary, neutral, success, warning, danger | Tokens: primary=#000000, secondary=#ffffff, 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
|
||||
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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Colorful
|
||||
colors:
|
||||
primary: "#3B82F6"
|
||||
secondary: "#8B5CF6"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Inter"
|
||||
fontSize: 2rem
|
||||
body-md:
|
||||
fontFamily: "Inter"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "12/14/16/20/24/32"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 8px
|
||||
md: 16px
|
||||
sourceScale: "8pt baseline grid"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Vibrant, high-contrast palettes and gradients for engaging, memorable, and modern user experiences.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** high-contrast, playful, premium
|
||||
- **Typography scale:** 12/14/16/20/24/32
|
||||
- **Typography fonts:** primary=Inter, display=Inter, mono=JetBrains Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 8pt baseline grid
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#3B82F6):** Token from style foundations.
|
||||
- **Secondary (#8B5CF6):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,82 @@
|
||||
---
|
||||
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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Contemporary
|
||||
colors:
|
||||
primary: "#C800DF"
|
||||
secondary: "#E60076"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Jost"
|
||||
fontSize: 3rem
|
||||
body-md:
|
||||
fontFamily: "Jost"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "Overpass Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "desktop-first expressive scale"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 8px
|
||||
md: 16px
|
||||
sourceScale: "comfortable density mode"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Current-era minimalist design with bento grids, dark mode support, and high-performance accessible layouts.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** modern, minimal, bold, playful
|
||||
- **Typography scale:** desktop-first expressive scale
|
||||
- **Typography fonts:** primary=Jost, display=Jost, mono=Overpass Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, secondary, neutral
|
||||
- **Spacing scale:** comfortable density mode
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#C800DF):** Token from style foundations.
|
||||
- **Secondary (#E60076):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
name: contemporary
|
||||
description: Current-era minimalist design with bento grids, dark mode support, and high-performance accessible layouts.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# contemporary Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for contemporary.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
Contemporary UI/UX design focuses on, minimalist, accessible, and high-performance, featuring Bento grids, dark mode, and, AI-powered personalization
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: modern, minimal, bold, playful
|
||||
- Typography scale: desktop-first expressive scale | Fonts: primary=Jost, display=Jost, mono=Overpass Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary, secondary, neutral | Tokens: primary=#C800DF, secondary=#E60076, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#FFFFFF, text=#111827
|
||||
- Spacing scale: comfortable density mode
|
||||
|
||||
|
||||
## 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, high-contrast support
|
||||
|
||||
## Writing Tone
|
||||
concise, confident, helpful, friendly, professional
|
||||
|
||||
## 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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Corporate
|
||||
colors:
|
||||
primary: "#3B82F6"
|
||||
secondary: "#8B5CF6"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Poppins"
|
||||
fontSize: 3rem
|
||||
body-md:
|
||||
fontFamily: "Open Sans"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "IBM Plex Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "desktop-first expressive scale"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 8px
|
||||
md: 16px
|
||||
sourceScale: "8pt baseline grid"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Professional, brand-aligned design with structured grids, minimalist layouts, and consistent enterprise patterns.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** enterprise, premium
|
||||
- **Typography scale:** desktop-first expressive scale
|
||||
- **Typography fonts:** primary=Open Sans, display=Poppins, mono=IBM Plex Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 8pt baseline grid
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#3B82F6):** Token from style foundations.
|
||||
- **Secondary (#8B5CF6):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,89 @@
|
||||
---
|
||||
name: corporate
|
||||
description: Professional, brand-aligned design with structured grids, minimalist layouts, and consistent enterprise patterns.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Corporate Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Corporate.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
Corporate UI/UX design focuses on professionalism, consistency, and brand alignment, typically featuring minimalist layouts, structured grids, and, in 2026, AI-driven personalization
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: enterprise, premium
|
||||
- Typography scale: desktop-first expressive scale | Fonts: primary=Open Sans, display=Poppins, mono=IBM Plex 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, high-contrast support
|
||||
|
||||
## Writing Tone
|
||||
concise, confident, helpful, clear, professional, action-oriented, low-jargon
|
||||
|
||||
## Rules: Do
|
||||
- prefer semantic tokens over raw values
|
||||
- preserve visual hierarchy
|
||||
- keep interaction states explicit
|
||||
- design for empty/loading/error states
|
||||
- ensure responsive behavior by default
|
||||
- document accessibility rationale
|
||||
|
||||
## Rules: Don't
|
||||
- avoid low contrast text
|
||||
- avoid inconsistent spacing rhythm
|
||||
- avoid decorative motion without purpose
|
||||
- avoid ambiguous labels
|
||||
- avoid mixing multiple visual metaphors
|
||||
- avoid inaccessible hit areas
|
||||
|
||||
## 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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Cosmic
|
||||
colors:
|
||||
primary: "#3B82F6"
|
||||
secondary: "#8B5CF6"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Audiowide"
|
||||
fontSize: 2rem
|
||||
body-md:
|
||||
fontFamily: "Audiowide"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "12/14/16/20/24/32"
|
||||
weights: "400"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Futuristic sci-fi aesthetic with dark themes, vibrant neon accents, and immersive spatial elements.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** playful, premium
|
||||
- **Typography scale:** 12/14/16/20/24/32
|
||||
- **Typography fonts:** primary=Audiowide, display=Audiowide, mono=JetBrains Mono
|
||||
- **Typography weights:** 400
|
||||
- **Color palette:** primary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#3B82F6):** Token from style foundations.
|
||||
- **Secondary (#8B5CF6):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
name: cosmic
|
||||
description: Futuristic sci-fi aesthetic with dark themes, vibrant neon accents, and immersive spatial elements.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Cosmic Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Cosmic.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
Cosmic UI/UX design is a futuristic, sci-fi-inspired style characterized by dark themes, vibrant neon accents, and immersive, spatial elements
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: playful, premium
|
||||
- Typography scale: 12/14/16/20/24/32 | Fonts: primary=Audiowide, display=Audiowide, mono=JetBrains Mono | weights=400
|
||||
- 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
|
||||
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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Creative
|
||||
colors:
|
||||
primary: "#3B82F6"
|
||||
secondary: "#8B5CF6"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Bangers"
|
||||
fontSize: 2rem
|
||||
body-md:
|
||||
fontFamily: "Bangers"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "IBM Plex Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "12/14/16/20/24/32"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Playful, character-driven design with expressive typography and bold graphics for landing pages and creative projects.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** playful
|
||||
- **Typography scale:** 12/14/16/20/24/32
|
||||
- **Typography fonts:** primary=Bangers, display=Bangers, mono=IBM Plex Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, secondary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#3B82F6):** Token from style foundations.
|
||||
- **Secondary (#8B5CF6):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
name: creative
|
||||
description: Playful, character-driven design with expressive typography and bold graphics for landing pages and creative projects.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Creative Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Creative.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
cerative style for landing pages
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: playful
|
||||
- Typography scale: 12/14/16/20/24/32 | Fonts: primary=Bangers, display=Bangers, mono=IBM Plex Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary, secondary, 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
|
||||
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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Dashboard
|
||||
colors:
|
||||
primary: "#0C5CAB"
|
||||
secondary: "#0a4a8a"
|
||||
success: "#10b981"
|
||||
warning: "#f59e0b"
|
||||
danger: "#ef4444"
|
||||
surface: "#09090b"
|
||||
text: "#fafafa"
|
||||
neutral: "#09090b"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "IBM Plex Sans"
|
||||
fontSize: 2rem
|
||||
body-md:
|
||||
fontFamily: "IBM Plex Sans"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "IBM Plex Sans"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "12/14/16/20/24/32"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 8px
|
||||
md: 16px
|
||||
sourceScale: "8pt baseline grid"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Dark-themed cloud-platform aesthetic with modular grids, glass-like panels, and strong data hierarchy for productivity dashboards.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** modern, clean, cloud-platform aesthetic (Heroku/Vercel/GitHub inspired), dark theme, subtle gradients, soft shadows, glass-like panels, rounded components
|
||||
- **Typography scale:** 12/14/16/20/24/32
|
||||
- **Typography fonts:** primary=IBM Plex Sans, display=IBM Plex Sans, mono=IBM Plex Sans
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 8pt baseline grid
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#0C5CAB):** Token from style foundations.
|
||||
- **Secondary (#0a4a8a):** Token from style foundations.
|
||||
- **Success (#10b981):** Token from style foundations.
|
||||
- **Warning (#f59e0b):** Token from style foundations.
|
||||
- **Danger (#ef4444):** Token from style foundations.
|
||||
- **Surface (#09090b):** Token from style foundations.
|
||||
- **Text (#fafafa):** Token from style foundations.
|
||||
- **Neutral (#09090b):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,89 @@
|
||||
---
|
||||
name: dashboard
|
||||
description: Dark-themed cloud-platform aesthetic with modular grids, glass-like panels, and strong data hierarchy for productivity dashboards.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Dashboard Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Dashboard.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
Dashboard design emphasizes grids, modular components, and strong visual hierarchy to present complex data in a clear and accessible way. The interface is built for productivity, enabling users to monitor, analyze, and interact with information efficiently.
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: modern, clean, cloud-platform aesthetic (Heroku/Vercel/GitHub inspired), dark theme, subtle gradients, soft shadows, glass-like panels, rounded components
|
||||
- Typography scale: 12/14/16/20/24/32 | Fonts: primary=IBM Plex Sans, display=IBM Plex Sans, mono=IBM Plex Sans | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary, neutral, success, warning, danger | Tokens: primary=#0C5CAB, secondary=#0a4a8a, success=#10b981, warning=#f59e0b, danger=#ef4444, surface=#09090b, text=#fafafa
|
||||
- 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, high-contrast support
|
||||
|
||||
## Writing Tone
|
||||
concise, confident, helpful, clear, friendly, professional, action-oriented, low-jargon
|
||||
|
||||
## Rules: Do
|
||||
- prefer semantic tokens over raw values
|
||||
- preserve visual hierarchy
|
||||
- keep interaction states explicit
|
||||
- design for empty/loading/error states
|
||||
- ensure responsive behavior by default
|
||||
- document accessibility rationale
|
||||
|
||||
## Rules: Don't
|
||||
- avoid low contrast text
|
||||
- avoid inconsistent spacing rhythm
|
||||
- avoid decorative motion without purpose
|
||||
- avoid ambiguous labels
|
||||
- avoid mixing multiple visual metaphors
|
||||
- avoid inaccessible hit areas
|
||||
|
||||
## 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 -->
|
||||
@@ -0,0 +1,62 @@
|
||||
# Neutral Modern
|
||||
|
||||
> Category: Starter
|
||||
> A clean, product-oriented default. Use when the brief doesn't call for a
|
||||
> specific mood — good for B2B tools, dashboards, and utility pages.
|
||||
|
||||
## Visual Theme & Atmosphere
|
||||
Calm, functional, quietly confident. No ornament. Content-first, chrome-second.
|
||||
|
||||
## Color Palette & Roles
|
||||
- **Background:** `#FAFAFA`
|
||||
- **Foreground:** `#111111`
|
||||
- **Accent:** `#2F6FEB` (cobalt) — primary CTAs, links, one hero element per screen
|
||||
- **Muted:** `#6B6B6B` — secondary text, captions
|
||||
- **Border:** `#E5E5E5`
|
||||
- **Surface:** `#FFFFFF` — cards, modals
|
||||
- **Success:** `#17A34A`, **Warn:** `#EAB308`, **Danger:** `#DC2626`
|
||||
Never pure black; never pure white for backgrounds.
|
||||
|
||||
## Typography Rules
|
||||
- **Display / headings:** `'Inter', -apple-system, system-ui, sans-serif`, weight 600
|
||||
- **Body:** `'Inter', -apple-system, system-ui, sans-serif`, weight 400
|
||||
- **Mono:** `ui-monospace, 'JetBrains Mono', monospace`
|
||||
- Scale (px): 12 · 14 · 16 · 20 · 24 · 32 · 48 · 64
|
||||
- Line-height: 1.5 for body, 1.2 for headings
|
||||
- Letter-spacing: -0.01em on display sizes ≥32px
|
||||
|
||||
## Component Stylings
|
||||
- **Buttons:** 8px radius, 10px padding-block, 16px padding-inline. Primary = cobalt fill, white label. Secondary = 1px border, transparent fill.
|
||||
- **Cards:** white, 1px border, 12px radius, 20px internal padding, no shadow by default.
|
||||
- **Inputs:** 1px border, 8px radius, 10px vertical padding, cobalt border on focus.
|
||||
- **Links:** cobalt, no underline, underline on hover.
|
||||
|
||||
## Layout Principles
|
||||
- 12-column grid, 1200px max-width, 24px gutters.
|
||||
- Hero: 40–60vh. Content top-biased, never centered vertically.
|
||||
- Sections: 80px top+bottom spacing desktop, 48px tablet, 32px phone.
|
||||
- Use whitespace as the main separator. Dividers only between unrelated top-level sections.
|
||||
|
||||
## Depth & Elevation
|
||||
Two levels only:
|
||||
- **Flat (0):** default.
|
||||
- **Raised (1):** dropdowns, modals, floating buttons. 2px y-offset, 8px blur, foreground at 8% opacity.
|
||||
No neumorphism, no glassmorphism.
|
||||
|
||||
## Do's and Don'ts
|
||||
- ✅ Let whitespace do the work.
|
||||
- ✅ One accent element per screen.
|
||||
- ✅ Sentence-case headings by default; title case only for brand names.
|
||||
- ❌ No gradients (except the accent → accent-at-80% on a hero, sparingly).
|
||||
- ❌ No drop shadows on inputs.
|
||||
- ❌ No more than three type sizes on one screen.
|
||||
|
||||
## Responsive Behavior
|
||||
- **Desktop ≥ 1024px:** 12-col grid.
|
||||
- **Tablet 640–1023px:** 8-col grid, 16px gutters.
|
||||
- **Phone < 640px:** 4-col grid, 12px gutters; hero drops to 40vh.
|
||||
|
||||
## Agent Prompt Guide
|
||||
- When in doubt, subtract. Fewer boxes, less chrome, more space.
|
||||
- Use the accent color sparingly — at most one hero accent and one CTA accent per screen.
|
||||
- Do not invent hex values outside this palette. If the request needs one, surface a warning comment in the artifact and use the closest existing token.
|
||||
@@ -0,0 +1,85 @@
|
||||
---
|
||||
name: default
|
||||
description: A clean, product-oriented default. Use when the brief doesn't call for a specific mood — good for B2B tools, dashboards, and utility pages. Content-first, chrome-second.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: hand-authored
|
||||
---
|
||||
|
||||
<!-- HAND_AUTHORED_MANAGED_START -->
|
||||
# Neutral Modern Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Neutral Modern.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers. This system is hand-authored; treat its DESIGN.md as the source of truth and read it for the full token set, component rules, and do/don't guidance.
|
||||
|
||||
## Brand
|
||||
Neutral Modern — calm, functional, neutral.
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: minimal, functional, quietly confident
|
||||
- Typography fonts: primary=Inter, display=Inter, mono=JetBrains Mono
|
||||
- Color palette: background, foreground, accent, muted, border, surface
|
||||
- Key tokens: background=#FAFAFA, foreground=#111111, accent=#2F6FEB, muted=#6B6B6B, border=#E5E5E5, surface=#FFFFFF, success=#17A34A, warning=#EAB308, danger=#DC2626
|
||||
- Spacing / layout: 12-column grid, 1200px max-width, 24px gutters; 80/48/32px section spacing
|
||||
|
||||
## Accessibility
|
||||
WCAG 2.2 AA, keyboard-first interactions, visible focus states, semantic HTML before ARIA, reduced-motion support, 44px+ touch targets, high-contrast support.
|
||||
|
||||
## Writing Tone
|
||||
calm, functional, neutral
|
||||
|
||||
## Rules: Do
|
||||
- prefer semantic tokens over raw values
|
||||
- preserve visual hierarchy
|
||||
- keep interaction states explicit
|
||||
- read DESIGN.md for the authoritative palette, type, and component rules
|
||||
|
||||
## Rules: Don't
|
||||
- avoid low contrast text
|
||||
- avoid inconsistent spacing rhythm
|
||||
- avoid ambiguous labels
|
||||
- do not invent hex values outside this system's palette
|
||||
|
||||
## 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.
|
||||
|
||||
<!-- HAND_AUTHORED_MANAGED_END -->
|
||||
@@ -0,0 +1,523 @@
|
||||
<!doctype html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
||||
<title>Neutral Modern — reference components</title>
|
||||
<meta
|
||||
name="description"
|
||||
content="Reference fixture for design-systems/default. Every visible
|
||||
value comes from tokens.css; if the agent paste-replaces the
|
||||
:root block and reuses the component selectors below verbatim,
|
||||
the artifact passes lint without further audit."
|
||||
/>
|
||||
|
||||
<style>
|
||||
/* :root paste — sourced verbatim from
|
||||
design-systems/default/tokens.css. Keep this block in sync
|
||||
when tokens.css changes. The agent prompt instructs the
|
||||
Designer panelist to paste this block as the FIRST thing in
|
||||
their <style>, then reference everything below via var(...). */
|
||||
:root {
|
||||
--bg: #fafafa;
|
||||
--surface: #ffffff;
|
||||
--surface-warm: var(--surface);
|
||||
|
||||
--fg: #111111;
|
||||
--fg-2: var(--fg);
|
||||
--muted: #6b6b6b;
|
||||
--meta: var(--muted);
|
||||
|
||||
--border: #e5e5e5;
|
||||
--border-soft: var(--border);
|
||||
|
||||
--accent: #2f6feb;
|
||||
--accent-on: #ffffff;
|
||||
--accent-hover: color-mix(in oklab, var(--accent), black 8%);
|
||||
--accent-active: color-mix(in oklab, var(--accent), black 14%);
|
||||
|
||||
--success: #17a34a;
|
||||
--warn: #eab308;
|
||||
--danger: #dc2626;
|
||||
|
||||
--font-display: "Inter", -apple-system, system-ui, sans-serif;
|
||||
--font-body: "Inter", -apple-system, system-ui, sans-serif;
|
||||
--font-mono: ui-monospace, "JetBrains Mono", monospace;
|
||||
|
||||
--text-xs: 12px;
|
||||
--text-sm: 14px;
|
||||
--text-base: 16px;
|
||||
--text-lg: 20px;
|
||||
--text-xl: 24px;
|
||||
--text-2xl: 32px;
|
||||
--text-3xl: 48px;
|
||||
--text-4xl: 64px;
|
||||
|
||||
--leading-body: 1.5;
|
||||
--leading-tight: 1.2;
|
||||
--tracking-display: -0.01em;
|
||||
|
||||
--space-1: 4px;
|
||||
--space-2: 8px;
|
||||
--space-3: 12px;
|
||||
--space-4: 16px;
|
||||
--space-5: 20px;
|
||||
--space-6: 24px;
|
||||
--space-8: 32px;
|
||||
--space-12: 48px;
|
||||
--space-20: 80px;
|
||||
|
||||
--section-y-desktop: 80px;
|
||||
--section-y-tablet: 48px;
|
||||
--section-y-phone: 32px;
|
||||
|
||||
--radius-sm: 8px;
|
||||
--radius-md: 12px;
|
||||
--radius-lg: 16px;
|
||||
--radius-pill: 9999px;
|
||||
|
||||
--elev-flat: none;
|
||||
--elev-ring: 0 0 0 1px var(--border);
|
||||
--elev-raised: 0 2px 8px
|
||||
color-mix(in oklab, var(--fg), transparent 92%);
|
||||
|
||||
--focus-ring: 0 0 0 3px
|
||||
color-mix(in oklab, var(--accent), transparent 70%);
|
||||
|
||||
--motion-fast: 150ms;
|
||||
--motion-base: 200ms;
|
||||
--ease-standard: cubic-bezier(0.2, 0, 0, 1);
|
||||
|
||||
--container-max: 1200px;
|
||||
--container-gutter-desktop: 24px;
|
||||
--container-gutter-tablet: 16px;
|
||||
--container-gutter-phone: 12px;
|
||||
}
|
||||
|
||||
/* ─── Reset (minimal) ───────────────────────────────────── */
|
||||
*, *::before, *::after { box-sizing: border-box; }
|
||||
html, body { margin: 0; padding: 0; }
|
||||
body {
|
||||
background: var(--bg);
|
||||
color: var(--fg);
|
||||
font-family: var(--font-body);
|
||||
font-size: var(--text-base);
|
||||
line-height: var(--leading-body);
|
||||
-webkit-font-smoothing: antialiased;
|
||||
}
|
||||
|
||||
/* ─── Layout primitives ─────────────────────────────────── */
|
||||
.container {
|
||||
max-width: var(--container-max);
|
||||
margin-inline: auto;
|
||||
padding-inline: var(--container-gutter-desktop);
|
||||
}
|
||||
section {
|
||||
padding-block: var(--section-y-desktop);
|
||||
}
|
||||
section + section {
|
||||
border-top: 1px solid var(--border);
|
||||
}
|
||||
@media (max-width: 1023px) {
|
||||
.container { padding-inline: var(--container-gutter-tablet); }
|
||||
section { padding-block: var(--section-y-tablet); }
|
||||
}
|
||||
@media (max-width: 639px) {
|
||||
.container { padding-inline: var(--container-gutter-phone); }
|
||||
section { padding-block: var(--section-y-phone); }
|
||||
}
|
||||
|
||||
/* ─── Typography ────────────────────────────────────────── */
|
||||
h1, h2, h3 {
|
||||
font-family: var(--font-display);
|
||||
line-height: var(--leading-tight);
|
||||
margin: 0;
|
||||
}
|
||||
h1 {
|
||||
font-size: var(--text-3xl);
|
||||
font-weight: 600;
|
||||
letter-spacing: var(--tracking-display);
|
||||
}
|
||||
h2 {
|
||||
font-size: var(--text-2xl);
|
||||
font-weight: 600;
|
||||
letter-spacing: var(--tracking-display);
|
||||
}
|
||||
h3 {
|
||||
font-size: var(--text-lg);
|
||||
font-weight: 600;
|
||||
}
|
||||
p { margin: 0; }
|
||||
.lead {
|
||||
font-size: var(--text-lg);
|
||||
color: var(--muted);
|
||||
}
|
||||
.body-muted { color: var(--muted); }
|
||||
.body-sm { font-size: var(--text-sm); }
|
||||
/* `.eyebrow` is the only component that uses uppercase + tracking.
|
||||
craft/typography.md requires letter-spacing ≥ 0.06em on any
|
||||
uppercase rule; the token below is well above that floor. */
|
||||
.eyebrow {
|
||||
font-size: var(--text-xs);
|
||||
color: var(--muted);
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.08em;
|
||||
font-weight: 500;
|
||||
}
|
||||
.stack-3 > * + * { margin-block-start: var(--space-3); }
|
||||
.stack-4 > * + * { margin-block-start: var(--space-4); }
|
||||
.stack-6 > * + * { margin-block-start: var(--space-6); }
|
||||
|
||||
/* ─── Buttons ───────────────────────────────────────────── */
|
||||
.btn {
|
||||
display: inline-flex;
|
||||
align-items: center;
|
||||
gap: var(--space-2);
|
||||
padding: 10px 16px;
|
||||
border-radius: var(--radius-sm);
|
||||
font-family: inherit;
|
||||
font-size: var(--text-sm);
|
||||
font-weight: 500;
|
||||
line-height: 1;
|
||||
cursor: pointer;
|
||||
border: 1px solid transparent;
|
||||
transition:
|
||||
transform var(--motion-fast) var(--ease-standard),
|
||||
background-color var(--motion-fast) var(--ease-standard),
|
||||
border-color var(--motion-fast) var(--ease-standard);
|
||||
text-decoration: none;
|
||||
}
|
||||
.btn:active { transform: translateY(1px); }
|
||||
.btn:focus-visible {
|
||||
outline: none;
|
||||
box-shadow: var(--focus-ring);
|
||||
}
|
||||
.btn-primary {
|
||||
background: var(--accent);
|
||||
color: var(--accent-on);
|
||||
}
|
||||
.btn-primary:hover {
|
||||
background: var(--accent-hover);
|
||||
}
|
||||
.btn-primary:active {
|
||||
background: var(--accent-active);
|
||||
}
|
||||
.btn-secondary {
|
||||
background: transparent;
|
||||
color: var(--fg);
|
||||
border-color: var(--border);
|
||||
}
|
||||
.btn-secondary:hover {
|
||||
background: var(--surface);
|
||||
border-color: color-mix(in oklab, var(--border), var(--fg) 20%);
|
||||
}
|
||||
|
||||
/* ─── Inputs ────────────────────────────────────────────── */
|
||||
.field {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: var(--space-2);
|
||||
}
|
||||
.field label {
|
||||
font-size: var(--text-sm);
|
||||
font-weight: 500;
|
||||
}
|
||||
.field input {
|
||||
padding: 10px 12px;
|
||||
border-radius: var(--radius-sm);
|
||||
border: 1px solid var(--border);
|
||||
background: var(--surface);
|
||||
color: var(--fg);
|
||||
font-family: inherit;
|
||||
font-size: var(--text-sm);
|
||||
outline: none;
|
||||
transition:
|
||||
border-color var(--motion-fast) var(--ease-standard),
|
||||
box-shadow var(--motion-fast) var(--ease-standard);
|
||||
}
|
||||
.field input:focus-visible {
|
||||
outline: none;
|
||||
border-color: var(--accent);
|
||||
box-shadow: var(--focus-ring);
|
||||
}
|
||||
.field input::placeholder { color: var(--muted); }
|
||||
.field-help {
|
||||
font-size: var(--text-xs);
|
||||
color: var(--muted);
|
||||
}
|
||||
|
||||
/* ─── Cards ─────────────────────────────────────────────── */
|
||||
.card {
|
||||
background: var(--surface);
|
||||
border: 1px solid var(--border);
|
||||
border-radius: var(--radius-md);
|
||||
padding: var(--space-5);
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: var(--space-3);
|
||||
}
|
||||
/* No left-border accent on cards — that pattern is in the
|
||||
lint's P0 list (`left-accent-card`). Use a hairline border
|
||||
all-around or rely on the surface contrast against --bg. */
|
||||
|
||||
/* ─── Badges ────────────────────────────────────────────── */
|
||||
.badge {
|
||||
display: inline-flex;
|
||||
align-items: center;
|
||||
gap: var(--space-2);
|
||||
padding: 2px var(--space-2);
|
||||
border-radius: var(--radius-pill);
|
||||
font-size: var(--text-xs);
|
||||
font-weight: 500;
|
||||
line-height: 1.6;
|
||||
}
|
||||
.badge-success {
|
||||
color: var(--success);
|
||||
background: color-mix(in oklab, var(--success), transparent 90%);
|
||||
}
|
||||
.badge-muted {
|
||||
color: var(--muted);
|
||||
background: color-mix(in oklab, var(--muted), transparent 88%);
|
||||
}
|
||||
.badge-dot {
|
||||
width: 6px;
|
||||
height: 6px;
|
||||
border-radius: 50%;
|
||||
background: currentColor;
|
||||
}
|
||||
|
||||
/* ─── Links ─────────────────────────────────────────────── */
|
||||
a {
|
||||
color: var(--accent);
|
||||
text-decoration: none;
|
||||
}
|
||||
a:hover {
|
||||
text-decoration: underline;
|
||||
text-underline-offset: 3px;
|
||||
}
|
||||
|
||||
/* ─── Kbd ───────────────────────────────────────────────── */
|
||||
kbd {
|
||||
font-family: var(--font-mono);
|
||||
font-size: var(--text-xs);
|
||||
padding: 2px 6px;
|
||||
border-radius: 4px;
|
||||
border: 1px solid var(--border);
|
||||
background: var(--surface);
|
||||
color: var(--muted);
|
||||
}
|
||||
|
||||
/* ─── Section-specific layout ───────────────────────────── */
|
||||
.hero-grid {
|
||||
display: grid;
|
||||
/* Asymmetric hero — left column wider — keeps it from looking
|
||||
like an AI-default centered template. */
|
||||
grid-template-columns: 1.4fr 1fr;
|
||||
gap: var(--space-12);
|
||||
align-items: end;
|
||||
}
|
||||
@media (max-width: 1023px) {
|
||||
.hero-grid { grid-template-columns: 1fr; gap: var(--space-8); }
|
||||
}
|
||||
.hero-actions {
|
||||
display: flex;
|
||||
gap: var(--space-3);
|
||||
margin-block-start: var(--space-6);
|
||||
}
|
||||
.hero-meta {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: var(--space-3);
|
||||
padding: var(--space-4);
|
||||
border: 1px solid var(--border);
|
||||
border-radius: var(--radius-md);
|
||||
background: var(--surface);
|
||||
}
|
||||
.features-grid {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(3, 1fr);
|
||||
gap: var(--space-5);
|
||||
}
|
||||
@media (max-width: 1023px) {
|
||||
.features-grid { grid-template-columns: 1fr 1fr; }
|
||||
}
|
||||
@media (max-width: 639px) {
|
||||
.features-grid { grid-template-columns: 1fr; }
|
||||
}
|
||||
.form-row {
|
||||
display: grid;
|
||||
grid-template-columns: 1.4fr 1fr;
|
||||
gap: var(--space-12);
|
||||
align-items: start;
|
||||
}
|
||||
@media (max-width: 1023px) {
|
||||
.form-row { grid-template-columns: 1fr; }
|
||||
}
|
||||
.form {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: var(--space-4);
|
||||
max-width: 420px;
|
||||
}
|
||||
.form-actions {
|
||||
display: flex;
|
||||
gap: var(--space-3);
|
||||
margin-block-start: var(--space-2);
|
||||
}
|
||||
.icon { width: 16px; height: 16px; flex-shrink: 0; }
|
||||
.row-between {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: space-between;
|
||||
gap: var(--space-3);
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<main class="container">
|
||||
<!-- ════════════════════════════════════════════════════════════
|
||||
HERO — exercises: h1, .lead, .eyebrow, .btn-primary,
|
||||
.btn-secondary, kbd, .badge-success, container, section,
|
||||
--space-* rhythm. Asymmetric grid on purpose.
|
||||
═══════════════════════════════════════════════════════════════ -->
|
||||
<section data-od-id="hero">
|
||||
<div class="hero-grid">
|
||||
<div class="stack-4">
|
||||
<p class="eyebrow">Reference fixture · default</p>
|
||||
<h1>One source for the values your team keeps re-deciding.</h1>
|
||||
<p class="lead" style="max-width: 52ch">
|
||||
A starter pack that turns brand decisions into shippable
|
||||
tokens — colors, type, spacing — so every interface
|
||||
inherits the same answer instead of reaching for a default.
|
||||
</p>
|
||||
<div class="hero-actions">
|
||||
<a href="./tokens.css" class="btn btn-primary">
|
||||
View tokens
|
||||
<svg
|
||||
class="icon"
|
||||
viewBox="0 0 24 24"
|
||||
fill="none"
|
||||
stroke="currentColor"
|
||||
stroke-width="1.75"
|
||||
stroke-linecap="round"
|
||||
stroke-linejoin="round"
|
||||
aria-hidden="true"
|
||||
>
|
||||
<path d="M5 12h14M13 6l6 6-6 6" />
|
||||
</svg>
|
||||
</a>
|
||||
<a href="./DESIGN.md" class="btn btn-secondary">Read the spec</a>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<aside class="hero-meta" aria-label="System status">
|
||||
<div class="row-between">
|
||||
<span class="body-sm">System status</span>
|
||||
<span class="badge badge-success">
|
||||
<span class="badge-dot" aria-hidden="true"></span>
|
||||
Stable
|
||||
</span>
|
||||
</div>
|
||||
<p class="body-sm body-muted">
|
||||
Last reviewed
|
||||
<time datetime="2026-05-11">2026-05-11</time> · v0.1
|
||||
</p>
|
||||
<p class="body-sm body-muted">
|
||||
Press <kbd>⌘</kbd> <kbd>K</kbd> to search tokens.
|
||||
</p>
|
||||
</aside>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<!-- ════════════════════════════════════════════════════════════
|
||||
FEATURES — exercises: h2, h3, .card, .body-muted, link,
|
||||
.features-grid. Each card describes a real property of this
|
||||
fixture (no "feature one/two/three" filler).
|
||||
═══════════════════════════════════════════════════════════════ -->
|
||||
<section data-od-id="features">
|
||||
<div class="stack-3">
|
||||
<p class="eyebrow">What this fixture exercises</p>
|
||||
<h2 style="max-width: 28ch">
|
||||
Every component below uses only var(--*) — no raw hex, no
|
||||
off-token type.
|
||||
</h2>
|
||||
</div>
|
||||
|
||||
<div class="features-grid" style="margin-block-start: var(--space-8)">
|
||||
<article class="card">
|
||||
<h3>Surface tokens</h3>
|
||||
<p class="body-muted body-sm">
|
||||
--bg, --surface, --fg, --muted, --border. The whole page
|
||||
derives from these five names; rebind them for any other
|
||||
brand and the layout follows.
|
||||
</p>
|
||||
<a href="./tokens.css" class="body-sm">Inspect tokens →</a>
|
||||
</article>
|
||||
|
||||
<article class="card">
|
||||
<h3>Accent discipline</h3>
|
||||
<p class="body-muted body-sm">
|
||||
--accent appears at most twice on this screen — the
|
||||
primary CTA and the focus ring. The hero status uses
|
||||
--success instead, so the page does not feel mono-blue.
|
||||
</p>
|
||||
<a href="./DESIGN.md" class="body-sm">Read the rule →</a>
|
||||
</article>
|
||||
|
||||
<article class="card">
|
||||
<h3>Type rhythm</h3>
|
||||
<p class="body-muted body-sm">
|
||||
Display and body share Inter but differ in size, weight,
|
||||
and tracking. No third type face, no fourth size on this
|
||||
screen.
|
||||
</p>
|
||||
<a href="./tokens.css" class="body-sm">Inspect typography →</a>
|
||||
</article>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<!-- ════════════════════════════════════════════════════════════
|
||||
FORM — exercises: .field, input :focus-visible, .btn-primary
|
||||
(reused), .btn-secondary, .field-help.
|
||||
═══════════════════════════════════════════════════════════════ -->
|
||||
<section data-od-id="form">
|
||||
<div class="form-row">
|
||||
<div class="stack-4">
|
||||
<p class="eyebrow">Form components</p>
|
||||
<h2>Inputs inherit the same tokens.</h2>
|
||||
<p class="body-muted" style="max-width: 48ch">
|
||||
Focus rings, borders, placeholder color — all derive from
|
||||
--accent and --border. The submit button reuses
|
||||
.btn-primary unchanged. No new token introduced for this
|
||||
section.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<form class="form" onsubmit="event.preventDefault();">
|
||||
<div class="field">
|
||||
<label for="email">Work email</label>
|
||||
<input
|
||||
id="email"
|
||||
type="email"
|
||||
placeholder="you@team.dev"
|
||||
autocomplete="email"
|
||||
required
|
||||
/>
|
||||
<p class="field-help">
|
||||
We'll send the spec PDF and nothing else.
|
||||
</p>
|
||||
</div>
|
||||
<div class="form-actions">
|
||||
<button type="submit" class="btn btn-primary">
|
||||
Send the spec
|
||||
</button>
|
||||
<button type="button" class="btn btn-secondary">
|
||||
Skip for now
|
||||
</button>
|
||||
</div>
|
||||
</form>
|
||||
</div>
|
||||
</section>
|
||||
</main>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,200 @@
|
||||
/* ─────────────────────────────────────────────────────────────────────────
|
||||
* design-systems/default/tokens.css
|
||||
*
|
||||
* Structured token bindings for "Neutral Modern" — the canonical
|
||||
* starter design system. This file is the *machine-readable* form of
|
||||
* the values described in `DESIGN.md`. Agents are expected to paste
|
||||
* the `:root { … }` block verbatim into the first `<style>` of every
|
||||
* artifact they generate against this design system, then reference
|
||||
* tokens via `var(--name)` from then on.
|
||||
*
|
||||
* Why this file exists:
|
||||
* DESIGN.md gives humans context ("Accent #2F6FEB — primary CTAs"),
|
||||
* but agents have to translate prose names like "Accent" into the
|
||||
* standard token names the lint enforces (`--accent`). That
|
||||
* translation is where token misuse happens. This file pre-translates
|
||||
* the brand once, so agents copy structure instead of inventing it.
|
||||
*
|
||||
* Contract sources:
|
||||
* - Standard token names: craft/color.md
|
||||
* (--bg / --surface / --fg / --muted / --border / --accent
|
||||
* / --success / --warn / --danger)
|
||||
* - Display-face contract: craft/anti-ai-slop.md
|
||||
* (--font-display, must be referenced via var())
|
||||
* - Lint enforcement: apps/daemon/src/lint-artifact.ts
|
||||
* (raw-hex >12 outside :root → P1; indigo laundering → P0)
|
||||
*
|
||||
* Schema notes (the shared schema grew from kami's stress test —
|
||||
* see design-systems/kami/tokens.css for the rich form, and the
|
||||
* #Gap N tags below for what each addition resolves):
|
||||
* #Gap 1 — 4-level foreground ramp (fg / fg-2 / muted / meta)
|
||||
* #Gap 2 — 3-level surface (bg / surface / surface-warm)
|
||||
* #Gap 3 — 2-level border (border / border-soft)
|
||||
* #Gap 4 — accent-hover binds to value, not formula
|
||||
* #Gap 5 — ring elevation as a first-class level (--elev-ring)
|
||||
*
|
||||
* Default doesn't differentiate every level kami needs, so the
|
||||
* shallow tokens (`--fg-2`, `--meta`, `--surface-warm`, `--border-soft`)
|
||||
* collapse to their richer siblings via `var()`. The names still
|
||||
* exist so components can reference them uniformly across brands.
|
||||
*
|
||||
* Keep this file additive: never invent token names not also documented
|
||||
* in DESIGN.md or the craft contracts. New brands cloning this template
|
||||
* should overwrite values, not rename keys.
|
||||
* ─────────────────────────────────────────────────────────────────── */
|
||||
|
||||
:root {
|
||||
/* ─── Surface (3 levels — #Gap 2) ─────────────────────────────────
|
||||
* Per craft/color.md: never pure black, never pure white. Default
|
||||
* uses #FAFAFA for bg and #FFFFFF for surface — the cream-to-white
|
||||
* contrast gives cards lift without a shadow. `--surface-warm` is a
|
||||
* schema slot for brands that need a tertiary tier (kami's warm-sand
|
||||
* button bg); default has no third tier and aliases it to surface. */
|
||||
--bg: #fafafa;
|
||||
--surface: #ffffff;
|
||||
--surface-warm: var(--surface); /* alias — default has no warm tier */
|
||||
|
||||
/* ─── Foreground ramp (4 levels — #Gap 1) ───────────────────────
|
||||
* Default differentiates only two text levels (primary + muted).
|
||||
* `--fg-2` and `--meta` are schema slots for brands with richer
|
||||
* ramps (kami uses near-black / dark-warm / olive / stone). They
|
||||
* alias here so components targeting the full ramp resolve. */
|
||||
--fg: #111111;
|
||||
--fg-2: var(--fg); /* alias — default has no secondary tier */
|
||||
--muted: #6b6b6b;
|
||||
--meta: var(--muted); /* alias — default has no metadata tier */
|
||||
|
||||
/* ─── Border (2 levels — #Gap 3) ────────────────────────────────
|
||||
* Default has one border weight; `--border-soft` is a schema slot
|
||||
* for brands with row-separator vs card-edge differentiation. */
|
||||
--border: #e5e5e5;
|
||||
--border-soft: var(--border); /* alias — default has no soft tier */
|
||||
|
||||
/* ─── Accent ──────────────────────────────────────────────────────
|
||||
* Cobalt — primary CTAs, links, ONE hero element per screen.
|
||||
* Hard cap of 2 visible uses per screen is enforced by lint
|
||||
* (`accent-overuse` P1 fires at >6 inline occurrences). */
|
||||
--accent: #2f6feb;
|
||||
--accent-on: #ffffff; /* fg when accent is the bg (e.g. button label) */
|
||||
|
||||
/* ─── Accent states (#Gap 4) ────────────────────────────────────
|
||||
* Hover and active variants for any element using --accent as bg.
|
||||
* Default's mid-luminance cobalt admits a black-mix formula
|
||||
* cleanly; that's a brand-specific binding, NOT a schema rule.
|
||||
* kami binds --accent-hover to var(--accent) (no color shift,
|
||||
* hover via elevation) because ink-blue is too dark for further
|
||||
* darkening to read; other brands with light accents must
|
||||
* hand-pick.
|
||||
*
|
||||
* Schema rule: every brand provides --accent-hover and
|
||||
* --accent-active. The binding strategy (formula / identity /
|
||||
* hand-picked) is brand-decided.
|
||||
*
|
||||
* Why these two are tokens (and other tints stay inline):
|
||||
* - cross-component (button, chip, tab, dropdown all need them)
|
||||
* - cross-mode reversal (dark-mode hover should mix white, not
|
||||
* black — token re-binding is one line per mode)
|
||||
* - cross-brand customization (formula breaks on light accents)
|
||||
* - lint-enforceable contract (every brand must provide these)
|
||||
* Other inline `color-mix(...)` calls in components don't yet hit
|
||||
* any of the above — promote them to tokens when a second use
|
||||
* appears. */
|
||||
--accent-hover: color-mix(in oklab, var(--accent), black 8%);
|
||||
--accent-active: color-mix(in oklab, var(--accent), black 14%);
|
||||
|
||||
/* ─── Semantic ────────────────────────────────────────────────────
|
||||
* Reserved for state, not decoration. Keep total semantic-color
|
||||
* pixels under 5% of the surface. */
|
||||
--success: #17a34a;
|
||||
--warn: #eab308;
|
||||
--danger: #dc2626;
|
||||
|
||||
/* ─── Typography ──────────────────────────────────────────────────
|
||||
* Inter for display is the documented "modern minimal" override
|
||||
* to anti-ai-slop's serif-display rule (see DESIGN.md
|
||||
* §Visual Theme & Atmosphere — "Calm, functional, quietly
|
||||
* confident"). Other brands should rebind --font-display to a
|
||||
* serif unless their direction is also tech/utility. */
|
||||
--font-display: "Inter", -apple-system, system-ui, sans-serif;
|
||||
--font-body: "Inter", -apple-system, system-ui, sans-serif;
|
||||
--font-mono: ui-monospace, "JetBrains Mono", monospace;
|
||||
|
||||
/* Type scale (px) — direct copy of DESIGN.md §Typography Rules */
|
||||
--text-xs: 12px;
|
||||
--text-sm: 14px;
|
||||
--text-base: 16px;
|
||||
--text-lg: 20px;
|
||||
--text-xl: 24px;
|
||||
--text-2xl: 32px;
|
||||
--text-3xl: 48px;
|
||||
--text-4xl: 64px;
|
||||
|
||||
--leading-body: 1.5;
|
||||
--leading-tight: 1.2;
|
||||
--tracking-display: -0.01em; /* applied to display sizes ≥32px */
|
||||
|
||||
/* ─── Spacing ─────────────────────────────────────────────────────
|
||||
* 4px base unit. Section rhythm (80/48/32) lives below as named
|
||||
* tokens because DESIGN.md §Layout Principles treats them as
|
||||
* breakpoint-specific decisions, not generic spacing. */
|
||||
--space-1: 4px;
|
||||
--space-2: 8px;
|
||||
--space-3: 12px;
|
||||
--space-4: 16px;
|
||||
--space-5: 20px;
|
||||
--space-6: 24px;
|
||||
--space-8: 32px;
|
||||
--space-12: 48px;
|
||||
--space-20: 80px;
|
||||
|
||||
--section-y-desktop: 80px;
|
||||
--section-y-tablet: 48px;
|
||||
--section-y-phone: 32px;
|
||||
|
||||
/* ─── Radius ──────────────────────────────────────────────────────
|
||||
* Two intents: small (button/input) and medium (card/modal).
|
||||
* `--radius-pill` reserved for chips/avatars; do not use it on
|
||||
* cards or buttons. */
|
||||
--radius-sm: 8px;
|
||||
--radius-md: 12px;
|
||||
--radius-lg: 16px;
|
||||
--radius-pill: 9999px;
|
||||
|
||||
/* ─── Elevation (3 levels — #Gap 5) ─────────────────────────────
|
||||
* Default uses two levels (flat + raised blur shadow) per its own
|
||||
* DESIGN.md §Depth & Elevation. The schema gains `--elev-ring` as
|
||||
* a first-class level so brands using ring shadows as primary
|
||||
* elevation (kami, paper, editorial) don't need to rebind
|
||||
* --elev-raised away from blur. Default declares all three; ring
|
||||
* is available for hairline edges where a 1px border would shift
|
||||
* layout. No fourth level — that's neumorphism territory. */
|
||||
--elev-flat: none;
|
||||
--elev-ring: 0 0 0 1px var(--border);
|
||||
--elev-raised: 0 2px 8px color-mix(in oklab, var(--fg), transparent 92%);
|
||||
|
||||
/* ─── Focus ring ──────────────────────────────────────────────────
|
||||
* Single source of truth for keyboard-focus indicators. Every
|
||||
* `:focus-visible` rule on buttons, inputs, links, and tabs must
|
||||
* use this token — uniform behavior is itself a brand signal, and
|
||||
* craft/accessibility-baseline.md treats focus visibility as a
|
||||
* non-negotiable. Implemented as a `box-shadow` so it layers
|
||||
* outside the element without affecting layout. */
|
||||
--focus-ring: 0 0 0 3px color-mix(in oklab, var(--accent), transparent 70%);
|
||||
|
||||
/* ─── Motion ──────────────────────────────────────────────────────
|
||||
* Two durations + one easing curve, per anti-ai-slop's "short,
|
||||
* purposeful transitions (150–250ms) with stable easing". Add a
|
||||
* third duration only when a real interaction needs it; do not
|
||||
* invent `--motion-slow` speculatively. */
|
||||
--motion-fast: 150ms; /* hover, focus, micro-states */
|
||||
--motion-base: 200ms; /* general state changes */
|
||||
--ease-standard: cubic-bezier(0.2, 0, 0, 1);
|
||||
|
||||
/* ─── Layout ──────────────────────────────────────────────────────
|
||||
* Container width and per-breakpoint gutter. Skill-side responsive
|
||||
* code reads these to decide grid columns. */
|
||||
--container-max: 1200px;
|
||||
--container-gutter-desktop: 24px;
|
||||
--container-gutter-tablet: 16px;
|
||||
--container-gutter-phone: 12px;
|
||||
}
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Dithered
|
||||
colors:
|
||||
primary: "#3B82F6"
|
||||
secondary: "#8B5CF6"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Space Grotesk"
|
||||
fontSize: 2.5rem
|
||||
body-md:
|
||||
fontFamily: "Open Sans"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "IBM Plex Mono"
|
||||
fontSize: 0.875rem
|
||||
sourceScale: "14/16/18/24/32/40"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Dot-pattern rendering technique that simulates shades with a limited palette for nostalgic, retro, high-contrast visuals.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** modern, minimal
|
||||
- **Typography scale:** 14/16/18/24/32/40
|
||||
- **Typography fonts:** primary=Open Sans, display=Space Grotesk, mono=IBM Plex Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#3B82F6):** Token from style foundations.
|
||||
- **Secondary (#8B5CF6):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,87 @@
|
||||
---
|
||||
name: dithered
|
||||
description: Dot-pattern rendering technique that simulates shades with a limited palette for nostalgic, retro, high-contrast visuals.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# dithered Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for dithered.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
Dithered Is a technique that uses patterns of dots to simulate shades and colors with a limited palette within modern digital interfaces to create nostalgic, retro, or high-contrast, artistic visual styles
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: modern, minimal
|
||||
- Typography scale: 14/16/18/24/32/40 | Fonts: primary=Open Sans, display=Space Grotesk, mono=IBM Plex 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
|
||||
- design for empty/loading/error states
|
||||
- ensure responsive behavior by default
|
||||
|
||||
## Rules: Don't
|
||||
- avoid low contrast text
|
||||
- avoid inconsistent spacing rhythm
|
||||
- avoid decorative motion without purpose
|
||||
- avoid ambiguous labels
|
||||
- avoid inaccessible hit areas
|
||||
|
||||
## 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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Doodle
|
||||
colors:
|
||||
primary: "#49B6E5"
|
||||
secondary: "#263D5B"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Delius Swash Caps"
|
||||
fontSize: 2.5rem
|
||||
body-md:
|
||||
fontFamily: "Delius Swash Caps"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.875rem
|
||||
sourceScale: "14/16/18/24/32/40"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Hand-drawn, sketch-like style with doodles, handwritten fonts, and imperfect lines for a playful, informal feel.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** playful
|
||||
- **Typography scale:** 14/16/18/24/32/40
|
||||
- **Typography fonts:** primary=Delius Swash Caps, display=Delius Swash Caps, mono=JetBrains Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, secondary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#49B6E5):** Token from style foundations.
|
||||
- **Secondary (#263D5B):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,97 @@
|
||||
---
|
||||
name: doodle
|
||||
description: Hand-drawn, sketch-like style with doodles, handwritten fonts, and imperfect lines for a playful, informal feel.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Doodle Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
|
||||
You are an expert design-system guideline author for Doodle.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
|
||||
a creative, playful, and informal style that utilizes doodles, sketches, handwritten fonts, and imperfect lines to foster emotional connection and a raw, artistic feel
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- Visual style: playful
|
||||
- Typography scale: 14/16/18/24/32/40 | Fonts: primary=Delius Swash Caps, display=Delius Swash Caps, mono=JetBrains Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary, secondary, neutral, success, warning, danger | Tokens: primary=#49B6E5, secondary=#263D5B, 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
|
||||
|
||||
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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Dramatic
|
||||
colors:
|
||||
primary: "#8B5CF6"
|
||||
secondary: "#F43F5E"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#09090B"
|
||||
text: "#FAFAFA"
|
||||
neutral: "#09090B"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Outfit"
|
||||
fontSize: 2rem
|
||||
body-md:
|
||||
fontFamily: "Outfit"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "12/14/16/20/24/32"
|
||||
weights: "400, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
High-contrast, theatrical design with bold layouts, immersive visuals, and unconventional compositions that command attention.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** modern, clean, high-contrast
|
||||
- **Typography scale:** 12/14/16/20/24/32
|
||||
- **Typography fonts:** primary=Outfit, display=Outfit, mono=JetBrains Mono
|
||||
- **Typography weights:** 400, 900
|
||||
- **Color palette:** primary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#8B5CF6):** Token from style foundations.
|
||||
- **Secondary (#F43F5E):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#09090B):** Token from style foundations.
|
||||
- **Text (#FAFAFA):** Token from style foundations.
|
||||
- **Neutral (#09090B):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
name: dramatic
|
||||
description: High-contrast, theatrical design with bold layouts, immersive visuals, and unconventional compositions that command attention.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Dramatic Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Dramatic.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
Dramatic design style is a trend characterized by high-contrast visuals, bold, unconventional layouts, and immersive, theatrical experiences designed to grab user attention.
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: modern, clean, high-contrast
|
||||
- Typography scale: 12/14/16/20/24/32 | Fonts: primary=Outfit, display=Outfit, mono=JetBrains Mono | weights=400, 900
|
||||
- Color palette: primary, neutral, success, warning, danger | Tokens: primary=#8B5CF6, secondary=#F43F5E, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#09090B, text=#FAFAFA
|
||||
- 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
|
||||
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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Editorial
|
||||
colors:
|
||||
primary: "#111111"
|
||||
secondary: "#f1f1f1"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Gelasio"
|
||||
fontSize: 2.5rem
|
||||
body-md:
|
||||
fontFamily: "Gelasio"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "Ubuntu Mono"
|
||||
fontSize: 0.875rem
|
||||
sourceScale: "14/16/18/24/32/40"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 8px
|
||||
md: 16px
|
||||
sourceScale: "8pt baseline grid"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Magazine-inspired editorial layout with refined serif typography, structured grids, and elegant reading experiences.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** modern, editorial
|
||||
- **Typography scale:** 14/16/18/24/32/40
|
||||
- **Typography fonts:** primary=Gelasio, display=Gelasio, mono=Ubuntu Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, secondary, neutral, success
|
||||
- **Spacing scale:** 8pt baseline grid
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#111111):** Token from style foundations.
|
||||
- **Secondary (#f1f1f1):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,86 @@
|
||||
---
|
||||
name: editorial
|
||||
description: Magazine-inspired editorial layout with refined serif typography, structured grids, and elegant reading experiences.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Editorial Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Editorial.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: modern, editorial
|
||||
- Typography scale: 14/16/18/24/32/40 | Fonts: primary=Gelasio, display=Gelasio, mono=Ubuntu Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary, secondary, neutral, success | Tokens: primary=#111111, secondary=#f1f1f1, 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, high-contrast support
|
||||
|
||||
## Writing Tone
|
||||
concise, confident, helpful, clear, friendly, professional, action-oriented, low-jargon
|
||||
|
||||
## Rules: Do
|
||||
- prefer semantic tokens over raw values
|
||||
- preserve visual hierarchy
|
||||
- keep interaction states explicit
|
||||
- design for empty/loading/error states
|
||||
- ensure responsive behavior by default
|
||||
- document accessibility rationale
|
||||
|
||||
## 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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Elegant
|
||||
colors:
|
||||
primary: "#3B82F6"
|
||||
secondary: "#8B5CF6"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Google Sans"
|
||||
fontSize: 2.5rem
|
||||
body-md:
|
||||
fontFamily: "Google Sans"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "Anonymous Pro"
|
||||
fontSize: 0.875rem
|
||||
sourceScale: "14/16/18/24/32/40"
|
||||
weights: "100, 200, 300, 400, 500, 600"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Graceful, refined aesthetic with delicate typography, minimal palettes, and polished layouts that exude sophistication.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** minimal, clean
|
||||
- **Typography scale:** 14/16/18/24/32/40
|
||||
- **Typography fonts:** primary=Google Sans, display=Google Sans, mono=Anonymous Pro
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600
|
||||
- **Color palette:** primary, secondary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#3B82F6):** Token from style foundations.
|
||||
- **Secondary (#8B5CF6):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
name: elegant
|
||||
description: Graceful, refined aesthetic with delicate typography, minimal palettes, and polished layouts that exude sophistication.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Elegant Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Elegant.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: minimal, clean
|
||||
- Typography scale: 14/16/18/24/32/40 | Fonts: primary=Google Sans, display=Google Sans, mono=Anonymous Pro | weights=100, 200, 300, 400, 500, 600
|
||||
- Color palette: primary, secondary, 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
|
||||
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 -->
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
name: Energetic
|
||||
colors:
|
||||
primary: "#EA580B"
|
||||
secondary: "#F59E0B"
|
||||
background: "#FFEDD5"
|
||||
surface: "#FDBA74"
|
||||
text: "#EA580C"
|
||||
neutral: "#FDBA74"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Limelight"
|
||||
fontSize: 3rem
|
||||
body-md:
|
||||
fontFamily: "Limelight"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "12/14/16/20/24/32/48"
|
||||
weights: "400"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32/48/64"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Dynamic, vibrant style with thick borders, geometric shapes, high-contrast colors, and expressive typography conveying motion and vitality.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** bold, geometric, vibrant, thick-bordered
|
||||
- **Typography scale:** 12/14/16/20/24/32/48
|
||||
- **Typography fonts:** primary=Limelight, display=Limelight, mono=JetBrains Mono
|
||||
- **Typography weights:** 400
|
||||
- **Color palette:** primary, secondary, neutral
|
||||
- **Spacing scale:** 4/8/12/16/24/32/48/64
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#EA580B):** Token from style foundations.
|
||||
- **Secondary (#F59E0B):** Token from style foundations.
|
||||
- **Background (#FFEDD5):** Token from style foundations.
|
||||
- **Surface (#FDBA74):** Token from style foundations.
|
||||
- **Text (#EA580C):** Token from style foundations.
|
||||
- **Neutral (#FDBA74):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,86 @@
|
||||
---
|
||||
name: energetic
|
||||
description: Dynamic, vibrant style with thick borders, geometric shapes, high-contrast colors, and expressive typography conveying motion and vitality.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Energetic Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Energetic.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
Energetic design style embodies vibrant, dynamic, and bold aesthetics. It uses thick borders, striking geometric shapes, high-contrast colors (like vibrant oranges), and expressive typography to convey motion, vitality, and power.
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: bold, geometric, vibrant, thick-bordered
|
||||
- Typography scale: 12/14/16/20/24/32/48 | Fonts: primary=Limelight, display=Limelight, mono=JetBrains Mono | weights=400
|
||||
- Color palette: primary, secondary, neutral | Tokens: primary=#EA580B, secondary=#F59E0B, background=#FFEDD5, surface=#FDBA74, text=#EA580C
|
||||
- Spacing scale: 4/8/12/16/24/32/48/64
|
||||
- Borders: Thick 4px borders are a signature element.
|
||||
|
||||
|
||||
## Accessibility
|
||||
WCAG 2.2 AA, keyboard-first interactions, visible focus states. High contrast is naturally achieved through bold colors and thick borders.
|
||||
|
||||
## Writing Tone
|
||||
punchy, dynamic, motivating, bold
|
||||
|
||||
## Rules: Do
|
||||
- prefer semantic tokens over raw values
|
||||
- use thick (4px) borders for structural elements and containers
|
||||
- preserve visual hierarchy with bold typography and scale
|
||||
- keep interaction states explicit with scale/transform animations
|
||||
|
||||
## Rules: Don't
|
||||
- avoid thin or delicate borders
|
||||
- avoid low contrast text
|
||||
- avoid inconsistent spacing rhythm
|
||||
- avoid subtle or slow animations; prefer snappy, spring-based motion
|
||||
|
||||
## 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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Enterprise
|
||||
colors:
|
||||
primary: "#072C2C"
|
||||
secondary: "#FF5F03"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#EDEADE"
|
||||
text: "#111827"
|
||||
neutral: "#EDEADE"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Oswald"
|
||||
fontSize: 3rem
|
||||
body-md:
|
||||
fontFamily: "Ubuntu"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "Ubuntu Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "desktop-first expressive scale"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 8px
|
||||
md: 16px
|
||||
sourceScale: "comfortable density mode"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Clean, high-contrast enterprise design for data-driven workflows with intuitive drag-and-drop patterns and structured layouts.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** clean, high-contrast, enterprise
|
||||
- **Typography scale:** desktop-first expressive scale
|
||||
- **Typography fonts:** primary=Ubuntu, display=Oswald, mono=Ubuntu Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, success, warning, danger
|
||||
- **Spacing scale:** comfortable density mode
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#072C2C):** Token from style foundations.
|
||||
- **Secondary (#FF5F03):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#EDEADE):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#EDEADE):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,88 @@
|
||||
---
|
||||
name: enterprise
|
||||
description: Clean, high-contrast enterprise design for data-driven workflows with intuitive drag-and-drop patterns and structured layouts.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Enterprise Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Enterprise.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
Everything you need – data, apps, and AI in an intuitive drag and drop interface to automate your workflows.
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: clean, high-contrast, enterprise
|
||||
- Typography scale: desktop-first expressive scale | Fonts: primary=Ubuntu, display=Oswald, mono=Ubuntu Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary, success, warning, danger | Tokens: primary=#072C2C, secondary=#FF5F03, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#EDEADE, text=#111827
|
||||
- Spacing scale: comfortable density mode
|
||||
|
||||
- patterns
|
||||
- images
|
||||
|
||||
## Accessibility
|
||||
WCAG 2.2 AA, keyboard-first interactions, visible focus states
|
||||
|
||||
## Writing Tone
|
||||
confident, helpful, friendly, professional
|
||||
|
||||
## 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 decorative motion without purpose
|
||||
- avoid ambiguous labels
|
||||
- avoid mixing multiple visual metaphors
|
||||
- avoid inaccessible hit areas
|
||||
|
||||
## 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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Expressive
|
||||
colors:
|
||||
primary: "#db2777"
|
||||
secondary: "#2563eb"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "IBM Plex Mono"
|
||||
fontSize: 2.5rem
|
||||
body-md:
|
||||
fontFamily: "IBM Plex Mono"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "IBM Plex Mono"
|
||||
fontSize: 0.875rem
|
||||
sourceScale: "14/16/18/24/32/40"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Vibrant, personality-driven design with bold colors, playful graphics, and dynamic layouts that balance creativity with structure.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** modern, playful
|
||||
- **Typography scale:** 14/16/18/24/32/40
|
||||
- **Typography fonts:** primary=IBM Plex Mono, display=IBM Plex Mono, mono=IBM Plex Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, secondary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#db2777):** Token from style foundations.
|
||||
- **Secondary (#2563eb):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
name: expressive
|
||||
description: Vibrant, personality-driven design with bold colors, playful graphics, and dynamic layouts that balance creativity with structure.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Expressive Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Expressive.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
A vibrant and visually engaging design style that uses bold colors, playful graphics, and dynamic layouts to create a strong personality. It emphasizes creativity and energy while maintaining clear structure and modern UI patterns.
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: modern, playful
|
||||
- Typography scale: 14/16/18/24/32/40 | Fonts: primary=IBM Plex Mono, display=IBM Plex Mono, mono=IBM Plex Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary, secondary, neutral, success, warning, danger | Tokens: primary=#db2777, secondary=#2563eb, 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
|
||||
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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Fantasy
|
||||
colors:
|
||||
primary: "#0250CC"
|
||||
secondary: "#FDC800"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "New Rocker"
|
||||
fontSize: 2rem
|
||||
body-md:
|
||||
fontFamily: "New Rocker"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "IBM Plex Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "12/14/16/20/24/32"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 8px
|
||||
md: 16px
|
||||
sourceScale: "8pt baseline grid"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Game-inspired fantasy aesthetic with bold, premium visuals, rich color palettes, and immersive thematic elements.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** bold, premium
|
||||
- **Typography scale:** 12/14/16/20/24/32
|
||||
- **Typography fonts:** primary=New Rocker, display=New Rocker, mono=IBM Plex Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, secondary, success, warning, danger, info
|
||||
- **Spacing scale:** 8pt baseline grid
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#0250CC):** Token from style foundations.
|
||||
- **Secondary (#FDC800):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
name: fantasy
|
||||
description: Game-inspired fantasy aesthetic with bold, premium visuals, rich color palettes, and immersive thematic elements.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Fantasy Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for fantasy.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
the best game in the world
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: bold, premium
|
||||
- Typography scale: 12/14/16/20/24/32 | Fonts: primary=New Rocker, display=New Rocker, mono=IBM Plex Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary, secondary, success, warning, danger, info | Tokens: primary=#0250CC, secondary=#FDC800, 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
|
||||
|
||||
## 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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Fiction
|
||||
colors:
|
||||
primary: "#222222"
|
||||
secondary: "#FFE9CE"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Cossette Texte"
|
||||
fontSize: 2rem
|
||||
body-md:
|
||||
fontFamily: "Cossette Texte"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "12/14/16/20/24/32"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Playful, storybook-inspired interface with warm surfaces, chunky outlines, and expressive display typography.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** playful
|
||||
- **Typography scale:** 12/14/16/20/24/32
|
||||
- **Typography fonts:** primary=Cossette Texte, display=Cossette Texte, mono=JetBrains Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#222222):** Token from style foundations.
|
||||
- **Secondary (#FFE9CE):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,81 @@
|
||||
---
|
||||
name: "fiction"
|
||||
description: "A playful, energetic, cartoonesque interface inspired by friendly children's-book illustrations — warm cream backgrounds, big bold custom display typography, saturated brand color blocks, thick black outlines, generously rounded shapes"
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Fiction Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Fiction.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
A playful, energetic, cartoonesque interface inspired by friendly children's-book illustrations — warm cream backgrounds, big bold custom display typography, saturated brand color blocks, thick black outlines, generously rounded shapes, flat surfaces with almost no shadows, and decorative hand-drawn-feeling illustrations in every section.
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: playful
|
||||
- Typography scale: 12/14/16/20/24/32 | Fonts: primary=Cossette Texte, display=Cossette Texte, mono=JetBrains Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary, neutral, success, warning, danger | Tokens: primary=#222222, secondary=#FFE9CE, 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
|
||||
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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Flat
|
||||
colors:
|
||||
primary: "#F2673C"
|
||||
secondary: "#8B5CF6"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Inter"
|
||||
fontSize: 2rem
|
||||
body-md:
|
||||
fontFamily: "Inter"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "12/14/16/20/24/32"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Two-dimensional minimalist style with vibrant colors, clean typography, and no 3D effects for fast, user-friendly interfaces.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** minimal, enterprise
|
||||
- **Typography scale:** 12/14/16/20/24/32
|
||||
- **Typography fonts:** primary=Inter, display=Inter, mono=JetBrains Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#F2673C):** Token from style foundations.
|
||||
- **Secondary (#8B5CF6):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
+101
@@ -0,0 +1,101 @@
|
||||
---
|
||||
name: flat
|
||||
description: Two-dimensional minimalist style with vibrant colors, clean typography, and no 3D effects for fast, user-friendly interfaces.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Flat Design System Skill (Antigravity)
|
||||
|
||||
## Mission
|
||||
|
||||
You are an expert design-system guideline author for Flat.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
|
||||
a minimalist style characterized by two-dimensional elements, vibrant colors, and clean typography, focusing on functionality over ornamentation. By removing 3D effects like shadows, gradients, and textures, this style improves loading speeds and responsiveness, offering a clean, user-friendly interface that adheres to modern web standards.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- Visual style: minimal, enterprise
|
||||
- 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=#F2673C, 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, clear, friendly, professional
|
||||
|
||||
## Rules: Do
|
||||
|
||||
- prefer semantic tokens over raw values
|
||||
- preserve visual hierarchy
|
||||
- keep interaction states explicit
|
||||
- design for empty/loading/error states
|
||||
- ensure responsive behavior by default
|
||||
|
||||
## Rules: Don't
|
||||
|
||||
- avoid low contrast text
|
||||
- avoid inconsistent spacing rhythm
|
||||
- avoid decorative motion without purpose
|
||||
- avoid ambiguous labels
|
||||
- avoid mixing multiple visual metaphors
|
||||
|
||||
## 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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Friendly
|
||||
colors:
|
||||
primary: "#F2D9DC"
|
||||
secondary: "#D9F2D8"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Noto Serif Display"
|
||||
fontSize: 2.5rem
|
||||
body-md:
|
||||
fontFamily: "Noto Serif Display"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "Space Mono"
|
||||
fontSize: 0.875rem
|
||||
sourceScale: "14/16/18/24/32/40"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "compact density mode"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Approachable, intuitive design with rounded elements, ample whitespace, and soft pastel color palettes.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** bold, playful, premium
|
||||
- **Typography scale:** 14/16/18/24/32/40
|
||||
- **Typography fonts:** primary=Noto Serif Display, display=Noto Serif Display, mono=Space Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, secondary, neutral
|
||||
- **Spacing scale:** compact density mode
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#F2D9DC):** Token from style foundations.
|
||||
- **Secondary (#D9F2D8):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
name: friendly
|
||||
description: Approachable, intuitive design with rounded elements, ample whitespace, and soft pastel color palettes.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Friendly Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Friendly.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
Friendly UI/UX design focuses on creating approachable, intuitive, and engaging experiences through, rounded elements, ample whitespace, and, soft, pastel, color, palettes
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: bold, playful, premium
|
||||
- Typography scale: 14/16/18/24/32/40 | Fonts: primary=Noto Serif Display, display=Noto Serif Display, mono=Space Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary, secondary, neutral | Tokens: primary=#F2D9DC, secondary=#D9F2D8, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#FFFFFF, text=#111827
|
||||
- Spacing scale: compact density mode
|
||||
|
||||
|
||||
## 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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Futuristic
|
||||
colors:
|
||||
primary: "#3B82F6"
|
||||
secondary: "#8B5CF6"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Audiowide"
|
||||
fontSize: 3rem
|
||||
body-md:
|
||||
fontFamily: "Roboto"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "Anonymous Pro"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "desktop-first expressive scale"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Forward-looking design with tech-inspired typography, modern layouts, and a sleek, innovation-driven aesthetic.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** modern
|
||||
- **Typography scale:** desktop-first expressive scale
|
||||
- **Typography fonts:** primary=Roboto, display=Audiowide, mono=Anonymous Pro
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#3B82F6):** Token from style foundations.
|
||||
- **Secondary (#8B5CF6):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
name: futuristic
|
||||
description: Forward-looking design with tech-inspired typography, modern layouts, and a sleek, innovation-driven aesthetic.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Futuristic Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Futuristic.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: modern
|
||||
- Typography scale: desktop-first expressive scale | Fonts: primary=Roboto, display=Audiowide, mono=Anonymous Pro | 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
|
||||
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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Glassmorphism
|
||||
colors:
|
||||
primary: "#1856FF"
|
||||
secondary: "#3A344E"
|
||||
success: "#07CA6B"
|
||||
warning: "#E89558"
|
||||
danger: "#EA2143"
|
||||
surface: "#FFFFFF"
|
||||
text: "#141414"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Plus Jakarta Sans"
|
||||
fontSize: 3rem
|
||||
body-md:
|
||||
fontFamily: "Plus Jakarta Sans"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "mobile-first compact scale"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 8px
|
||||
md: 16px
|
||||
sourceScale: "comfortable density mode"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Frosted glass effect with translucent layers, subtle blur, and luminous borders for depth and modern elegance.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** clean, high-contrast, bold, enterprise, liquidglass effect, glassmorphism
|
||||
- **Typography scale:** mobile-first compact scale
|
||||
- **Typography fonts:** primary=Plus Jakarta Sans, display=Plus Jakarta Sans, mono=JetBrains Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, neutral, success, warning, danger, info, surface/subtle layers
|
||||
- **Spacing scale:** comfortable density mode
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#1856FF):** Token from style foundations.
|
||||
- **Secondary (#3A344E):** Token from style foundations.
|
||||
- **Success (#07CA6B):** Token from style foundations.
|
||||
- **Warning (#E89558):** Token from style foundations.
|
||||
- **Danger (#EA2143):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#141414):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,86 @@
|
||||
---
|
||||
name: glassmorphism
|
||||
description: Frosted glass effect with translucent layers, subtle blur, and luminous borders for depth and modern elegance.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Glassmorphism Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Glassmorphism.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
provide fast, reliable communication for individuals, teams, and communities while maintaining a clean interface and high performance across desktop environments.
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: clean, high-contrast, bold, enterprise, liquidglass effect, glassmorphism
|
||||
- Typography scale: mobile-first compact scale | Fonts: primary=Plus Jakarta Sans, display=Plus Jakarta Sans, mono=JetBrains Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary, neutral, success, warning, danger, info, surface/subtle layers | Tokens: primary=#1856FF, secondary=#3A344E, success=#07CA6B, warning=#E89558, danger=#EA2143, surface=#FFFFFF, text=#141414
|
||||
- Spacing scale: comfortable density mode
|
||||
|
||||
- bento cards
|
||||
|
||||
## Accessibility
|
||||
WCAG 2.2 AA, keyboard-first interactions, visible focus states
|
||||
|
||||
## Writing Tone
|
||||
concise, confident, helpful, clear, friendly, professional
|
||||
|
||||
## 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 decorative motion without purpose
|
||||
- avoid ambiguous labels
|
||||
- avoid mixing multiple visual metaphors
|
||||
|
||||
## 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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Gradient
|
||||
colors:
|
||||
primary: "#990FFA"
|
||||
secondary: "#E60076"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Space Grotesk"
|
||||
fontSize: 2.25rem
|
||||
body-md:
|
||||
fontFamily: "Montserrat"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "12/14/16/18/24/30/36"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 8px
|
||||
md: 16px
|
||||
sourceScale: "8pt baseline grid"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Smooth color transitions and gradient-rich surfaces for modern, playful interfaces with visual depth.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** modern, playful
|
||||
- **Typography scale:** 12/14/16/18/24/30/36
|
||||
- **Typography fonts:** primary=Montserrat, display=Space Grotesk, mono=JetBrains Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, secondary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 8pt baseline grid
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#990FFA):** Token from style foundations.
|
||||
- **Secondary (#E60076):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
name: gradient
|
||||
description: Smooth color transitions and gradient-rich surfaces for modern, playful interfaces with visual depth.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Gradient Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Gradient.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
Gradient design style
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: modern, playful
|
||||
- Typography scale: 12/14/16/18/24/30/36 | Fonts: primary=Montserrat, display=Space Grotesk, mono=JetBrains Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary, secondary, neutral, success, warning, danger | Tokens: primary=#990FFA, secondary=#E60076, 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, 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 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 -->
|
||||
+173
@@ -0,0 +1,173 @@
|
||||
# HUD Design System
|
||||
|
||||
> Category: Themed & Unique
|
||||
> Fighter jet / helicopter head-up display. Phosphor green on near-black, all-caps data overlays, angular geometry. Zero ambiguity at speed and altitude.
|
||||
|
||||
## 1. Visual Theme & Atmosphere
|
||||
|
||||
A **combat pilot's glass cockpit** — everything readable in a split second, in any light condition, under any G-load. The HUD projects critical flight data directly into the pilot's line of sight so they never have to look down. Translucency and glow replace depth and shadow. Every element is functional or it doesn't exist.
|
||||
|
||||
| Element | Hex | Role |
|
||||
|---------|-----|------|
|
||||
| Background | `#0A0A0A` | Near-black, primary canvas |
|
||||
| Surface | `#111316` | Elevated panels, card backgrounds |
|
||||
| Border | `#1E2328` | Subtle panel separation |
|
||||
| Primary | `#00FF41` | Active readouts, all data values |
|
||||
| Secondary | `#7FFF00` | Standby/dimmed values, inactive fields |
|
||||
| Tertiary | `#5A9A5A` | Grid lines, tick marks, reference arcs |
|
||||
| Warning | `#FFB800` | Caution, system advisories |
|
||||
| Alert | `#FF3B3B` | Critical warnings, fault indicators |
|
||||
|
||||
*Readings must be unambiguous at 200 knots in Instrument Meteorological Conditions.*
|
||||
|
||||
### Use Cases
|
||||
|
||||
HUD is purpose-built for:
|
||||
- **Flight simulation UIs** — combat sims, civil aviation trainers, helicopter hoist operations
|
||||
- **Telemetry dashboards** — real-time velocity, altitude, heading overlays
|
||||
- **Command-and-control displays** — drone operator screens, ISR stations
|
||||
- **Any high-speed, zero-ambiguity data overlay**
|
||||
|
||||
### Prior Art
|
||||
|
||||
F-16 Fighting Falcon HUD, Apache AH-64 attack helicopter integrated display, F-35 helmet-mounted display system, Garmin G1000 flight deck. All share: phosphor green primary, decluttered minimalism, and information hierarchy driven by operational urgency.
|
||||
|
||||
## 2. Color Palette & Roles
|
||||
|
||||
### Surface Palette
|
||||
|
||||
| Token | Hex | Usage |
|
||||
|-------|-----|-------|
|
||||
| Background | `#0A0A0A` | Page canvas, primary depth |
|
||||
| Surface | `#111316` | Panels, cards, elevated areas |
|
||||
| Border | `#1E2328` | Panel dividers, subtle structure |
|
||||
|
||||
### Data Palette
|
||||
|
||||
| Token | Hex | Usage |
|
||||
|-------|-----|-------|
|
||||
| Primary | `#00FF41` | Speed, altitude, heading readouts |
|
||||
| Secondary | `#7FFF00` | Standby/dimmed values, inactive fields |
|
||||
| Tertiary | `#5A9A5A` | Grid lines, tick marks, reference arcs |
|
||||
| Warning | `#FFB800` | Caution, system advisories |
|
||||
| Alert | `#FF3B3B` | Critical warnings, fault indicators |
|
||||
|
||||
All data colors on `#0A0A0A` pass WCAG AA (minimum 4.5:1).
|
||||
|
||||
### Dark Mode
|
||||
|
||||
Dark mode is the native and only mode. A HUD is projected in low-light or high-glare cockpit conditions; there is no light mode by design.
|
||||
|
||||
```css
|
||||
:root {
|
||||
--color-bg: #0A0A0A;
|
||||
--color-surface: #111316;
|
||||
--color-border: #1E2328;
|
||||
--data-primary: #00FF41;
|
||||
--data-secondary: #7FFF00;
|
||||
--data-tertiary: #5A9A5A;
|
||||
--data-warning: #FFB800;
|
||||
--data-alert: #FF3B3B;
|
||||
}
|
||||
```
|
||||
|
||||
## 3. Typography Rules
|
||||
|
||||
| Role | Size | Weight | Line Height | Font |
|
||||
|------|------|--------|-------------|------|
|
||||
| Display | 32px | 700 | 1.0 | JetBrains Mono |
|
||||
| Heading | 12px | 700 | 1.0 | Inter, uppercase |
|
||||
| Body | 14px | 400 | 1.2 | JetBrains Mono |
|
||||
| Label | 10px | 600 | 1.0 | Inter, uppercase |
|
||||
| Micro | 8px | 700 | 1.0 | Inter, uppercase |
|
||||
|
||||
**Font labels for catalog extraction:**
|
||||
|
||||
```
|
||||
Display: "JetBrains Mono", ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, monospace
|
||||
Body: "JetBrains Mono", ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, monospace
|
||||
Heading: "Inter", -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif
|
||||
Label: "Inter", -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif
|
||||
Micro: "Inter", -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif
|
||||
Mono: "JetBrains Mono", ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, monospace
|
||||
```
|
||||
|
||||
## 4. Component Stylings
|
||||
|
||||
### Data Readout
|
||||
|
||||
Displays a single data value with label. Always uses `--data-primary` color.
|
||||
|
||||
```css
|
||||
.data-readout {
|
||||
font-family: 'JetBrains Mono', monospace;
|
||||
font-size: 14px;
|
||||
font-weight: 700;
|
||||
color: var(--data-primary);
|
||||
letter-spacing: 0.05em;
|
||||
}
|
||||
.data-readout-label {
|
||||
font-family: 'Inter', sans-serif;
|
||||
font-size: 10px;
|
||||
font-weight: 600;
|
||||
text-transform: uppercase;
|
||||
color: var(--data-tertiary);
|
||||
letter-spacing: 0.1em;
|
||||
}
|
||||
```
|
||||
|
||||
### Status Indicator
|
||||
|
||||
Dot or bar that reflects system state. Colors map to operational states.
|
||||
|
||||
```css
|
||||
.status-dot {
|
||||
width: 8px;
|
||||
height: 8px;
|
||||
border-radius: 50%;
|
||||
background: var(--data-primary); /* active */
|
||||
}
|
||||
.status-dot.standby { background: var(--data-secondary); }
|
||||
.status-dot.warning { background: var(--data-warning); }
|
||||
.status-dot.alert { background: var(--data-alert); }
|
||||
```
|
||||
|
||||
### Grid Lines
|
||||
|
||||
Reference marks for spatial orientation. Thin lines in `--data-tertiary`.
|
||||
|
||||
## 5. Layout Principles
|
||||
|
||||
HUDs are overlay systems — they display over a visual field. The layout is absolute-positioned overlays on a transparent or dark background. Information density is high; whitespace is used to separate data clusters, not for aesthetics.
|
||||
|
||||
Key structural patterns:
|
||||
- Grid lines reference the center of the display (crosshair)
|
||||
- Data readouts cluster by update frequency (altitude updates slower than airspeed)
|
||||
- Warning states override all other information layers
|
||||
|
||||
## 6. Depth & Elevation
|
||||
|
||||
HUD overlays use opacity and glow rather than elevation shadows. Panels are distinguished by border color and subtle surface shifts, not drop shadows. The HUD exists in a single visual plane.
|
||||
|
||||
## 7. Do's and Don'ts
|
||||
|
||||
- Do not use tertiary `#5A9A5A` for body or readout text — only grid lines and reference marks
|
||||
- Do not animate elements that do not signal operational state
|
||||
- Do not provide a light mode — a HUD only exists in low-light or high-glare conditions
|
||||
- Do not use rounded corners greater than 50% (circle reticles only)
|
||||
- Do not use gradients — flat color fills only
|
||||
- Do not convey information by color alone — reinforce with position and label
|
||||
|
||||
## 8. Responsive Behavior
|
||||
|
||||
HUD overlays are viewport-relative. On smaller viewports, data clusters compress proportionally. Critical readouts (speed, altitude, heading) remain visible at all sizes; secondary indicators hide or minimize. The layout uses a 12-column grid with absolute-positioned data panels anchored to screen edges.
|
||||
|
||||
## 9. Agent Prompt Guide
|
||||
|
||||
When generating a HUD-style interface, prompt the model to:
|
||||
- Use JetBrains Mono for all data readouts; Inter (uppercase) for labels only
|
||||
- Set `--data-primary` to `#00FF41` for all active readouts
|
||||
- Apply 150ms ease-out for state transitions, 100ms linear for data value changes
|
||||
- Include a status indicator component with active/standby/warning/alert states
|
||||
- Ensure all text passes 4.5:1 contrast on `#0A0A0A`
|
||||
- Never add decorative animation or light mode variants
|
||||
+85
@@ -0,0 +1,85 @@
|
||||
---
|
||||
name: hud
|
||||
description: Fighter-jet / helicopter head-up display: phosphor green on near-black, all-caps data overlays, angular geometry. Zero ambiguity at speed and altitude. For flight-sim UIs, telemetry, and command-and-control displays.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: hand-authored
|
||||
---
|
||||
|
||||
<!-- HAND_AUTHORED_MANAGED_START -->
|
||||
# HUD Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for HUD.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers. This system is hand-authored; treat its DESIGN.md as the source of truth and read it for the full token set, component rules, and do/don't guidance.
|
||||
|
||||
## Brand
|
||||
HUD — operational, urgent, unambiguous.
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: themed, high-contrast, decluttered, glow-over-depth
|
||||
- Typography fonts: primary=monospace, display=monospace, mono=monospace
|
||||
- Color palette: phosphor-green primary, near-black canvas, caution amber, alert red
|
||||
- Key tokens: background=#0A0A0A, surface=#111316, border=#1E2328, primary=#00FF41, secondary=#7FFF00, tertiary=#5A9A5A, warning=#FFB800, alert=#FF3B3B
|
||||
- Spacing / layout: dense functional grid; readable at 200 knots in IMC
|
||||
|
||||
## Accessibility
|
||||
WCAG 2.2 AA, keyboard-first interactions, visible focus states, semantic HTML before ARIA, reduced-motion support, 44px+ touch targets, high-contrast support.
|
||||
|
||||
## Writing Tone
|
||||
operational, urgent, unambiguous
|
||||
|
||||
## Rules: Do
|
||||
- prefer semantic tokens over raw values
|
||||
- preserve visual hierarchy
|
||||
- keep interaction states explicit
|
||||
- read DESIGN.md for the authoritative palette, type, and component rules
|
||||
|
||||
## Rules: Don't
|
||||
- avoid low contrast text
|
||||
- avoid inconsistent spacing rhythm
|
||||
- avoid ambiguous labels
|
||||
- do not invent hex values outside this system's palette
|
||||
|
||||
## 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.
|
||||
|
||||
<!-- HAND_AUTHORED_MANAGED_END -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Immersive
|
||||
colors:
|
||||
primary: "#00592B"
|
||||
secondary: "#0023D1"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Oswald"
|
||||
fontSize: 2rem
|
||||
body-md:
|
||||
fontFamily: "Oswald"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "12/14/16/20/24/32"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Exhibit-style interface that blends storytelling and game-like interaction on a continuous deep-green canvas.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** modern, clean, high-contrast
|
||||
- **Typography scale:** 12/14/16/20/24/32
|
||||
- **Typography fonts:** primary=Oswald, display=Oswald, mono=JetBrains Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#00592B):** Token from style foundations.
|
||||
- **Secondary (#0023D1):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,81 @@
|
||||
---
|
||||
name: "immersive"
|
||||
description: "An immersive, interactive, exhibit-style interface that blends storytelling, animation, and gamified elements to create a playful, experience-driven journey. The entire app sits on a single continuous brand-colored canvas (deep green)"
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Immersive Design System Skill (Cursor)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Immersive.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
An immersive, interactive, exhibit-style interface that blends storytelling, animation, and gamified elements to create a playful, experience-driven journey. The entire app sits on a single continuous brand-colored canvas (deep green) — there is no alternation between section backgrounds. Crisp white cards with thick black borders, hard offset block shadows, and oversized condensed display typography (Oswald) punch off that canvas. Buttons are skewed white blocks with hard black shadows that grow on hover, like posters or arcade signs reacting to the player. Decorative geometric blocks in brand-tertiary (cobalt blue) and brand-quaternary (hot pink) layer behind cards to add depth without breaking the brand-color continuity. The result feels less like browsing a website and more like exploring a digital exhibit.
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: modern, clean, high-contrast
|
||||
- Typography scale: 12/14/16/20/24/32 | Fonts: primary=Oswald, sans-serif, display=Oswald, sans-serif, mono=JetBrains Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary, neutral, success, warning, danger | Tokens: primary=#00592B, secondary=#0023D1, 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
|
||||
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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Impeccable
|
||||
colors:
|
||||
primary: "#CC8800"
|
||||
secondary: "#C55221"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Chakra Petch"
|
||||
fontSize: 2rem
|
||||
body-md:
|
||||
fontFamily: "Chakra Petch"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "12/14/16/20/24/32"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Graphic editorial-poster aesthetic with warm cream and burnt-orange rhythm plus a sharp amber accent.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** modern, clean, high-contrast
|
||||
- **Typography scale:** 12/14/16/20/24/32
|
||||
- **Typography fonts:** primary=Chakra Petch, display=Chakra Petch, mono=JetBrains Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#CC8800):** Token from style foundations.
|
||||
- **Secondary (#C55221):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,81 @@
|
||||
---
|
||||
name: "impeccable"
|
||||
description: "A modern, graphic, editorial-poster aesthetic — warm and confident — built on alternating cream and burnt orange sections, an amber brand color."
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Impeccable Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Impeccable.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
A modern, graphic, editorial-poster aesthetic — warm and confident — built on alternating cream and burnt orange sections, an amber brand color.
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: modern, clean, high-contrast
|
||||
- Typography scale: 12/14/16/20/24/32 | Fonts: primary=Chakra Petch, display=Chakra Petch, mono=JetBrains Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary, neutral, success, warning, danger | Tokens: primary=#CC8800, secondary=#C55221, 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
|
||||
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 -->
|
||||
+1151
File diff suppressed because it is too large.
Load diff
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Levels
|
||||
colors:
|
||||
primary: "#27272A"
|
||||
secondary: "#8B5CF6"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Inter"
|
||||
fontSize: 2rem
|
||||
body-md:
|
||||
fontFamily: "Inter"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "12/14/16/20/24/32"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Conversion-focused design that removes friction and guides users toward action through clarity, trust, and speed.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** modern, clean
|
||||
- **Typography scale:** 12/14/16/20/24/32
|
||||
- **Typography fonts:** primary=Inter, display=Inter, mono=JetBrains Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#27272A):** Token from style foundations.
|
||||
- **Secondary (#8B5CF6):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
name: levels
|
||||
description: Conversion-focused design that removes friction and guides users toward action through clarity, trust, and speed.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# levels Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for levels.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
Levels design focuses on removing friction, building trust, and guiding users toward a specific action through clarity, psychology, and speed
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: modern, clean
|
||||
- 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=#27272A, 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
|
||||
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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Lingo
|
||||
colors:
|
||||
primary: "#58cc02"
|
||||
secondary: "#ce82ff"
|
||||
success: "#58cc02"
|
||||
warning: "#ffc800"
|
||||
danger: "#ff4b4b"
|
||||
surface: "#FFFFFF"
|
||||
text: "#3c3c3c"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Nunito"
|
||||
fontSize: 2rem
|
||||
body-md:
|
||||
fontFamily: "Nunito"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "12/14/16/20/24/32"
|
||||
weights: "400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Playful, minimal design with bright colors, rounded shapes, tactile 3D borders, and friendly illustrations for approachable interfaces.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** bold, playful
|
||||
- **Typography scale:** 12/14/16/20/24/32
|
||||
- **Typography fonts:** primary=Nunito, display=Nunito, mono=JetBrains Mono
|
||||
- **Typography weights:** 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#58cc02):** Token from style foundations.
|
||||
- **Secondary (#ce82ff):** Token from style foundations.
|
||||
- **Success (#58cc02):** Token from style foundations.
|
||||
- **Warning (#ffc800):** Token from style foundations.
|
||||
- **Danger (#ff4b4b):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#3c3c3c):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,87 @@
|
||||
---
|
||||
name: lingo
|
||||
description: Playful, minimal design with bright colors, rounded shapes, tactile 3D borders, and friendly illustrations for approachable interfaces.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Lingo Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Lingo.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
Lingo is a duolingo inspired design style that combines minimal layouts with bright colors, rounded shapes, and friendly illustrations to create an engaging and approachable interface. It focuses on clarity and simplicity while adding personality that makes the product feel welcoming and interactive.
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: bold, playful
|
||||
- Typography scale: 12/14/16/20/24/32 | Fonts: primary=Nunito, display=Nunito, mono=JetBrains Mono | weights=400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary, neutral, success, warning, danger | Tokens: primary=#58cc02, secondary=#ce82ff, success=#58cc02, warning=#ffc800, danger=#ff4b4b, surface=#FFFFFF, text=#3c3c3c
|
||||
- Shadows: tactile 3D-like bottom borders (e.g., border-b-4) or soft drop shadows for interactive elements
|
||||
- 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 decorative motion without purpose
|
||||
- avoid ambiguous labels
|
||||
- avoid mixing multiple visual metaphors
|
||||
- avoid inaccessible hit areas
|
||||
|
||||
## 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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Luxury
|
||||
colors:
|
||||
primary: "#FAFAFA"
|
||||
secondary: "#FAFAFA"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#000000"
|
||||
text: "#ffffff"
|
||||
neutral: "#000000"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Oswald"
|
||||
fontSize: 3rem
|
||||
body-md:
|
||||
fontFamily: "Oswald"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "desktop-first expressive scale"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 8px
|
||||
md: 16px
|
||||
sourceScale: "8pt baseline grid"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
High-end dark aesthetic with bold headings, monochromatic palette, and premium feel for luxury brand experiences.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** modern, bold, big headings
|
||||
- **Typography scale:** desktop-first expressive scale
|
||||
- **Typography fonts:** primary=Oswald, display=Oswald, mono=JetBrains Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary
|
||||
- **Spacing scale:** 8pt baseline grid
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#FAFAFA):** Token from style foundations.
|
||||
- **Secondary (#FAFAFA):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#000000):** Token from style foundations.
|
||||
- **Text (#ffffff):** Token from style foundations.
|
||||
- **Neutral (#000000):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
name: luxury
|
||||
description: High-end dark aesthetic with bold headings, monochromatic palette, and premium feel for luxury brand experiences.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Luxury Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Luxury.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: modern, bold, big headings
|
||||
- Typography scale: desktop-first expressive scale | Fonts: primary=Oswald, display=Oswald, mono=JetBrains Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary | Tokens: primary=#FAFAFA, secondary=#FAFAFA, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#000000, text=#ffffff
|
||||
- Spacing scale: 8pt baseline grid
|
||||
|
||||
|
||||
## Accessibility
|
||||
keyboard-first interactions, visible focus states, semantic HTML before ARIA, 44px+ touch targets, high-contrast support
|
||||
|
||||
## 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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Material
|
||||
colors:
|
||||
primary: "#6442D6"
|
||||
secondary: "#C8B3FD"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Roboto"
|
||||
fontSize: 2rem
|
||||
body-md:
|
||||
fontFamily: "Inter"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "Fira Code"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "12/14/16/20/24/32"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Google's Material Design with layered surfaces, dynamic theming, built-in motion, and responsive cross-platform patterns.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** modern, minimal, clean
|
||||
- **Typography scale:** 12/14/16/20/24/32
|
||||
- **Typography fonts:** primary=Inter, display=Roboto, mono=Fira Code
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, secondary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#6442D6):** Token from style foundations.
|
||||
- **Secondary (#C8B3FD):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,97 @@
|
||||
---
|
||||
name: material
|
||||
description: Google's Material Design with layered surfaces, dynamic theming, built-in motion, and responsive cross-platform patterns.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Material Design System Skill (Antigravity)
|
||||
|
||||
## Mission
|
||||
|
||||
You are an expert design-system guideline author for Material.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
|
||||
UX (user experience) designers use it to create visually consistent, intuitive, and responsive digital experiences. With built-in motion, layering, and dynamic theming, Material Design helps teams deliver accessible, high-quality UIs (user interfaces) across devices and platforms.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- Visual style: modern, minimal, clean
|
||||
- Typography scale: 12/14/16/20/24/32 | Fonts: primary=Inter, display=Roboto, mono=Fira Code | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary, secondary, neutral, success, warning, danger | Tokens: primary=#6442D6, secondary=#C8B3FD, 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
|
||||
|
||||
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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Matrix
|
||||
colors:
|
||||
primary: "#2DB58A"
|
||||
secondary: "#0B0C14"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Space Mono"
|
||||
fontSize: 2rem
|
||||
body-md:
|
||||
fontFamily: "Space Mono"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "Space Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "12/14/16/20/24/32"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Dark cyber-terminal visual language with mono typography, dense data layouts, and one green interaction accent.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** high-contrast
|
||||
- **Typography scale:** 12/14/16/20/24/32
|
||||
- **Typography fonts:** primary=Space Mono, display=Space Mono, mono=Space Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#2DB58A):** Token from style foundations.
|
||||
- **Secondary (#0B0C14):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,82 @@
|
||||
---
|
||||
name: "matrix"
|
||||
description: "A cyber-slick, dark-only Matrix-inspired interface defined by minimalist fashion, high-tech digital elements"
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Matrix Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Matrix.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
A cyber-slick, dark-only Matrix-inspired interface defined by minimalist fashion, high-tech digital elements, monospaced typography, and a single deep monochromatic surface. The aesthetic borrows from order-book exchanges and terminal interfaces: ultra-dense layouts, mono numerics, hairline borders, near-square 2px corners, a single brand-green accent that drives every interaction, and a flat dark surface across every section.
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: high-contrast
|
||||
- Typography scale: 12/14/16/20/24/32 | Fonts: primary=Space Mono, display=Space Mono, mono=Space Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary, neutral, success, warning, danger | Tokens: primary=#2DB58A, secondary=#0B0C14, 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, clear, friendly
|
||||
|
||||
## Rules: Do
|
||||
- prefer semantic tokens over raw values
|
||||
- preserve visual hierarchy
|
||||
- keep interaction states explicit
|
||||
- design for empty/loading/error states
|
||||
|
||||
## 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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Minimal
|
||||
colors:
|
||||
primary: "#0C0C09"
|
||||
secondary: "#312C85"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#F4F4F1"
|
||||
text: "#0C0C09"
|
||||
neutral: "#F4F4F1"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Inter"
|
||||
fontSize: 3rem
|
||||
body-md:
|
||||
fontFamily: "Open Sans"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "Inconsolata"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "desktop-first expressive scale"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Stripped-back design emphasizing whitespace, clean typography, and restrained color for maximum clarity and focus.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** minimal, clean, bold
|
||||
- **Typography scale:** desktop-first expressive scale
|
||||
- **Typography fonts:** primary=Open Sans, display=Inter, mono=Inconsolata
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#0C0C09):** Token from style foundations.
|
||||
- **Secondary (#312C85):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#F4F4F1):** Token from style foundations.
|
||||
- **Text (#0C0C09):** Token from style foundations.
|
||||
- **Neutral (#F4F4F1):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
name: minimal
|
||||
description: Stripped-back design emphasizing whitespace, clean typography, and restrained color for maximum clarity and focus.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Minimal Design Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for minimal design.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: minimal, clean, bold
|
||||
- Typography scale: desktop-first expressive scale | Fonts: primary=Open Sans, display=Inter, mono=Inconsolata | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary, neutral, success, warning, danger | Tokens: primary=#0C0C09, secondary=#312C85, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#F4F4F1, text=#0C0C09
|
||||
- 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
|
||||
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 -->
|
||||
@@ -0,0 +1,474 @@
|
||||
# Mission Control Design System
|
||||
|
||||
> Category: Developer Tools
|
||||
> Space/aerospace mission monitoring. Dark command center, amber telemetry, monospace precision. Functional clarity above all else.
|
||||
|
||||
## 1. Visual Theme & Atmosphere
|
||||
|
||||
A **deep space command center** — dark, information-dense, unambiguous. Every pixel earns its place. The aesthetic draws from NASA mission control rooms, SpaceX launch consoles, and ISRO's mission operations complex. Amber data on navy is the core contrast pair; everything else is subdued.
|
||||
|
||||
| Element | Hex | Role |
|
||||
|---------|-----|------|
|
||||
| Background | `#0B1120` | Deep space navy, primary canvas |
|
||||
| Surface | `#111827` | Elevated panels, cards |
|
||||
| Surface Hover | `#1A2535` | Interactive surface hover |
|
||||
| Border | `#1E3A5F` | Panel dividers, subtle structure |
|
||||
| Primary Data | `#FFB800` | Telemetry values, key metrics |
|
||||
| Accent | `#00D4FF` | Active/healthy indicators |
|
||||
| Alert | `#FF4757` | Critical warnings, errors |
|
||||
| Text Primary | `#E8F0FE` | High-contrast readable text |
|
||||
| Text Secondary | `#8BA3C7` | Labels, secondary information |
|
||||
| Text Tertiary | `#4A6080` | Timestamps, metadata |
|
||||
|
||||
*Every readout must be readable at 3 meters in low light by someone who hasn't slept in 18 hours.*
|
||||
|
||||
### Use Cases
|
||||
|
||||
Mission Control is purpose-built for:
|
||||
- **Operations dashboards** — real-time system health, infrastructure monitoring, on-call status boards
|
||||
- **Build and deploy status screens** — CI/CD pipelines, release coordination, incident response
|
||||
- **Real-time monitoring UIs** — telemetry aggregation, sensor networks, financial data feeds
|
||||
- **Any information-dense, low-light, high-stakes display**
|
||||
|
||||
### Prior Art
|
||||
|
||||
NASA Mission Control (Houston), ISRO ISTRAC, SpaceX Falcon/Dragon consoles, ESA ESOC — all share amber-on-navy telemetry, monospace data fields, and hierarchical alert systems. The shared constraints (low light, fatigue, split-second decisions) drive convergent design.
|
||||
|
||||
## 2. Color
|
||||
|
||||
### Surface Palette
|
||||
|
||||
| Token | Hex | Usage |
|
||||
|-------|-----|-------|
|
||||
| Background | `#0B1120` | Page canvas, primary depth |
|
||||
| Surface | `#111827` | Panels, cards, elevated areas |
|
||||
| Surface Hover | `#1A2535` | Interactive surface state |
|
||||
| Surface Active | `#1E3A5F` | Selected, active panel |
|
||||
| Border | `#1E3A5F` | Panel dividers, grid lines |
|
||||
| Border Subtle | `#162035` | Inner dividers, minor separation |
|
||||
|
||||
### Data Palette (telemetry values)
|
||||
|
||||
| Token | Hex | Usage |
|
||||
|-------|-----|-------|
|
||||
| Primary | `#FFB800` | Primary telemetry values, key metrics |
|
||||
| Secondary | `#00D4FF` | Healthy/active indicators, links |
|
||||
| Alert Critical | `#FF4757` | Errors, critical alerts, abort states |
|
||||
| Alert Warning | `#FF9F43` | Warnings, degraded performance |
|
||||
| Success | `#26DE81` | Nominal status, completed actions |
|
||||
|
||||
All data colors on `#111827` pass WCAG AA (minimum 4.5:1).
|
||||
|
||||
### Text Palette
|
||||
|
||||
| Token | Hex | Usage |
|
||||
|-------|-----|-------|
|
||||
| Primary | `#E8F0FE` | Readable at distance, primary content |
|
||||
| Secondary | `#8BA3C7` | Labels, descriptors |
|
||||
| Tertiary | `#4A6080` | Timestamps, metadata, grid labels |
|
||||
|
||||
### Dark Mode
|
||||
|
||||
Dark mode is the native mode. No light mode variant by design — mission control environments are always low-light (ISRO ISTRAC, NASA FDO, SpaceX launch consoles all run dark). daytime operations centers with high ambient light are outside scope for v1; a light mode adaptation would require rethinking the full semantic color layer.
|
||||
|
||||
```css
|
||||
:root {
|
||||
--bg-default: #0B1120;
|
||||
--bg-surface: #111827;
|
||||
--bg-surface-hover: #1A2535;
|
||||
--bg-surface-active: #1E3A5F;
|
||||
--border-default: #1E3A5F;
|
||||
--border-subtle: #162035;
|
||||
--data-primary: #FFB800;
|
||||
--data-secondary: #00D4FF;
|
||||
--data-alert-critical: #FF4757;
|
||||
--data-alert-warning: #FF9F43;
|
||||
--data-success: #26DE81;
|
||||
--fg-primary: #E8F0FE;
|
||||
--fg-secondary: #8BA3C7;
|
||||
--fg-tertiary: #4A6080;
|
||||
}
|
||||
```
|
||||
|
||||
## 3. Typography
|
||||
|
||||
### Font Stack
|
||||
|
||||
```css
|
||||
/* Monospace for all data readouts — consistency at speed */
|
||||
--font-mono: "JetBrains Mono", ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, monospace;
|
||||
|
||||
/* Sans-serif for labels, navigation, prose */
|
||||
--font-sans: "Inter", -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif;
|
||||
```
|
||||
|
||||
### Type Scale
|
||||
|
||||
| Role | Size | Weight | Line Height | Font |
|
||||
|------|------|--------|-------------|------|
|
||||
| Display | 48px | 700 | 1.0 | JetBrains Mono |
|
||||
| H1 | 18px | 600 | 1.2 | Inter |
|
||||
| H2 | 13px | 600 | 1.2 | Inter, uppercase, tracked |
|
||||
| Body | 14px | 400 | 1.5 | Inter |
|
||||
| Caption | 12px | 400 | 1.4 | Inter |
|
||||
| Micro | 10px | 600 | 1.0 | Inter, uppercase |
|
||||
|
||||
**Font labels for catalog extraction:**
|
||||
|
||||
```
|
||||
Display: "JetBrains Mono", ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, monospace
|
||||
Body: "Inter", -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif
|
||||
Mono: "JetBrains Mono", ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, monospace
|
||||
```
|
||||
|
||||
## 4. Spacing
|
||||
|
||||
4px baseline grid for dense telemetry layouts. 8px for outer padding, 16px+ for section gaps.
|
||||
|
||||
```css
|
||||
--space-1: 4px; --space-2: 8px; --space-3: 12px; --space-4: 16px;
|
||||
--space-5: 20px; --space-6: 24px; --space-8: 32px; --space-12: 48px;
|
||||
--space-16: 64px; --space-20: 80px;
|
||||
```
|
||||
|
||||
## 5. Layout & Composition
|
||||
|
||||
### Grid System
|
||||
|
||||
12-column grid, 4px gutters. Dense information layout — no wasted whitespace, but clear visual grouping.
|
||||
|
||||
```css
|
||||
/* Standard panel: spans 3, 4, or 6 columns */
|
||||
.panel {
|
||||
background: var(--bg-surface);
|
||||
border: 1px solid var(--border-default);
|
||||
border-radius: 4px;
|
||||
padding: var(--space-4);
|
||||
}
|
||||
|
||||
/* Full-width telemetry strip */
|
||||
.telemetry-strip {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(auto-fit, minmax(160px, 1fr));
|
||||
gap: var(--space-2);
|
||||
}
|
||||
```
|
||||
|
||||
### Panel Structure
|
||||
|
||||
```css
|
||||
/* .panel base styles are defined in the Grid System section above. */
|
||||
|
||||
.panel-header {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: space-between;
|
||||
margin-bottom: var(--space-3);
|
||||
padding-bottom: var(--space-2);
|
||||
border-bottom: 1px solid var(--border-subtle);
|
||||
}
|
||||
|
||||
.panel-title {
|
||||
font-size: 13px;
|
||||
font-weight: 600;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.08em;
|
||||
color: var(--fg-secondary);
|
||||
}
|
||||
```
|
||||
|
||||
## 6. Components
|
||||
|
||||
### Status Badge
|
||||
|
||||
```css
|
||||
/* Nominal — green, all clear */
|
||||
.badge-nominal {
|
||||
background: rgba(38, 222, 129, 0.15);
|
||||
color: #26DE81;
|
||||
border: 1px solid rgba(38, 222, 129, 0.3);
|
||||
font-size: 10px;
|
||||
font-weight: 600;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.05em;
|
||||
padding: 2px 8px;
|
||||
border-radius: 2px;
|
||||
}
|
||||
|
||||
/* Warning — amber, attention needed */
|
||||
.badge-warning {
|
||||
background: rgba(255, 159, 67, 0.15);
|
||||
color: #FF9F43;
|
||||
border: 1px solid rgba(255, 159, 67, 0.3);
|
||||
font-size: 10px;
|
||||
font-weight: 600;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.05em;
|
||||
padding: 2px 8px;
|
||||
border-radius: 2px;
|
||||
}
|
||||
|
||||
/* Critical — red, immediate action */
|
||||
.badge-critical {
|
||||
background: rgba(255, 71, 87, 0.15);
|
||||
color: #FF4757;
|
||||
border: 1px solid rgba(255, 71, 87, 0.3);
|
||||
font-size: 10px;
|
||||
font-weight: 600;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.05em;
|
||||
padding: 2px 8px;
|
||||
border-radius: 2px;
|
||||
}
|
||||
```
|
||||
|
||||
### Data Tile
|
||||
|
||||
```css
|
||||
/* Single metric display */
|
||||
.data-tile {
|
||||
background: var(--bg-surface);
|
||||
border: 1px solid var(--border-default);
|
||||
border-radius: 4px;
|
||||
padding: var(--space-3);
|
||||
}
|
||||
|
||||
.data-tile-label {
|
||||
font-size: 11px;
|
||||
font-weight: 600;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.08em;
|
||||
color: var(--fg-secondary);
|
||||
margin-bottom: var(--space-1);
|
||||
}
|
||||
|
||||
.data-tile-value {
|
||||
font-family: var(--font-mono);
|
||||
font-size: 24px;
|
||||
font-weight: 700;
|
||||
color: var(--data-primary);
|
||||
line-height: 1.0;
|
||||
}
|
||||
|
||||
.data-tile-unit {
|
||||
font-family: var(--font-mono);
|
||||
font-size: 12px;
|
||||
font-weight: 400;
|
||||
color: var(--fg-tertiary);
|
||||
margin-left: 4px;
|
||||
}
|
||||
```
|
||||
|
||||
### Countdown Timer
|
||||
|
||||
```css
|
||||
/* T-minus / T-plus display */
|
||||
.countdown {
|
||||
font-family: var(--font-mono);
|
||||
font-size: 48px;
|
||||
font-weight: 700;
|
||||
color: var(--data-primary);
|
||||
line-height: 1.0;
|
||||
letter-spacing: -0.02em;
|
||||
}
|
||||
|
||||
.countdown-label {
|
||||
font-size: 11px;
|
||||
font-weight: 600;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.1em;
|
||||
color: var(--fg-tertiary);
|
||||
}
|
||||
|
||||
/* Positive delta (T+) — time after event */
|
||||
.countdown.positive { color: var(--data-success); }
|
||||
|
||||
/* At T-0 */
|
||||
.countdown.zero { color: var(--data-secondary); animation: pulse-glow 2s ease-in-out infinite; }
|
||||
|
||||
@keyframes pulse-glow {
|
||||
0%, 100% { text-shadow: 0 0 8px currentColor; }
|
||||
50% { text-shadow: 0 0 20px currentColor, 0 0 40px currentColor; }
|
||||
}
|
||||
```
|
||||
|
||||
### Signal Strength Indicator
|
||||
|
||||
```css
|
||||
/* Vertical bar signal meter */
|
||||
.signal-bars {
|
||||
display: flex;
|
||||
align-items: flex-end;
|
||||
gap: 2px;
|
||||
height: 20px;
|
||||
}
|
||||
|
||||
.signal-bar {
|
||||
width: 4px;
|
||||
background: var(--border-default);
|
||||
border-radius: 1px;
|
||||
}
|
||||
|
||||
.signal-bar.active.weak { background: var(--data-alert-warning); }
|
||||
.signal-bar.active.moderate { background: var(--data-primary); }
|
||||
.signal-bar.active.strong { background: var(--data-secondary); }
|
||||
|
||||
.signal-bar:nth-child(1) { height: 5px; }
|
||||
.signal-bar:nth-child(2) { height: 8px; }
|
||||
.signal-bar:nth-child(3) { height: 12px; }
|
||||
.signal-bar:nth-child(4) { height: 16px; }
|
||||
```
|
||||
|
||||
### Alert Banner
|
||||
|
||||
```css
|
||||
/* Full-width critical alert */
|
||||
.alert-banner {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: var(--space-3);
|
||||
background: rgba(255, 71, 87, 0.1);
|
||||
border: 1px solid rgba(255, 71, 87, 0.4);
|
||||
border-left: 4px solid #FF4757;
|
||||
border-radius: 4px;
|
||||
padding: var(--space-3) var(--space-4);
|
||||
}
|
||||
|
||||
.alert-banner-icon {
|
||||
color: #FF4757;
|
||||
flex-shrink: 0;
|
||||
}
|
||||
|
||||
.alert-banner-text {
|
||||
font-size: 14px;
|
||||
font-weight: 500;
|
||||
color: #FF4757;
|
||||
}
|
||||
|
||||
.alert-banner-time {
|
||||
font-family: var(--font-mono);
|
||||
font-size: 11px;
|
||||
color: var(--fg-tertiary);
|
||||
margin-left: auto;
|
||||
flex-shrink: 0;
|
||||
}
|
||||
```
|
||||
|
||||
### Coordinate Display
|
||||
|
||||
```css
|
||||
/* Latitude / Longitude / Altitude readout */
|
||||
.coordinate {
|
||||
font-family: var(--font-mono);
|
||||
font-size: 14px;
|
||||
color: var(--data-secondary);
|
||||
}
|
||||
|
||||
.coordinate-label {
|
||||
font-size: 10px;
|
||||
font-weight: 600;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.08em;
|
||||
color: var(--fg-tertiary);
|
||||
margin-bottom: 2px;
|
||||
}
|
||||
```
|
||||
|
||||
### Progress Bar
|
||||
|
||||
```css
|
||||
/* Mission phase / upload / loading progress */
|
||||
.progress-bar {
|
||||
height: 4px;
|
||||
background: var(--border-default);
|
||||
border-radius: 2px;
|
||||
overflow: hidden;
|
||||
}
|
||||
|
||||
.progress-bar-fill {
|
||||
height: 100%;
|
||||
background: var(--data-secondary);
|
||||
border-radius: 2px;
|
||||
transition: width 300ms ease-out;
|
||||
}
|
||||
|
||||
.progress-bar-fill.warning { background: var(--data-alert-warning); }
|
||||
.progress-bar-fill.critical { background: var(--data-alert-critical); }
|
||||
```
|
||||
|
||||
### Telemetry Chart Line
|
||||
|
||||
```css
|
||||
/* Sparkline chart for data over time */
|
||||
.telemetry-chart {
|
||||
height: 40px;
|
||||
display: flex;
|
||||
align-items: flex-end;
|
||||
gap: 1px;
|
||||
}
|
||||
|
||||
.telemetry-chart-bar {
|
||||
flex: 1;
|
||||
background: var(--data-primary);
|
||||
border-radius: 1px 1px 0 0;
|
||||
min-width: 2px;
|
||||
}
|
||||
|
||||
.telemetry-chart-bar.alert { background: var(--data-alert-critical); }
|
||||
.telemetry-chart-bar.warning { background: var(--data-alert-warning); }
|
||||
```
|
||||
|
||||
## 7. Motion & Interaction
|
||||
|
||||
| Interaction | Duration | Easing | Effect |
|
||||
|-------------|----------|--------|--------|
|
||||
| Alert pulse | 2s | ease-in-out | Glow intensity oscillation (loop) |
|
||||
| Panel appear | 200ms | ease-out | Opacity 0→1 |
|
||||
| Value change | 150ms | ease-out | Background flash on new data |
|
||||
| Progress fill | 300ms | ease-out | Width transition |
|
||||
| Hover state | 100ms | ease-in | Border color brightens |
|
||||
|
||||
```css
|
||||
--transition-fast: 100ms ease-in;
|
||||
--transition-base: 150ms ease-out;
|
||||
--transition-slow: 300ms ease-out;
|
||||
```
|
||||
|
||||
### prefers-reduced-motion
|
||||
|
||||
Static environments are common in mission control. Replace all animations with instant state changes.
|
||||
|
||||
```css
|
||||
@media (prefers-reduced-motion: reduce) {
|
||||
*, *::before, *::after {
|
||||
animation-duration: 0.01ms !important;
|
||||
animation-iteration-count: 1 !important;
|
||||
transition-duration: 0.01ms !important;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 8. Voice & Brand
|
||||
|
||||
### Iconography
|
||||
|
||||
Minimal, functional iconography — Lucide icons (stroke weight 1.5px, 16px default). No decorative icons. Every icon must communicate operational state.
|
||||
|
||||
### Tone
|
||||
|
||||
- **Precise**: Data-first, no marketing language
|
||||
- **Sparse**: The UI speaks through values and color, not prose
|
||||
- **Hierarchical**: Visual urgency maps directly to operational urgency
|
||||
|
||||
### Visual Signals
|
||||
|
||||
Color is the primary signal carrier. Every color choice must communicate operational state — never decorative.
|
||||
|
||||
## 9. Anti-patterns
|
||||
|
||||
- Do not use decorative colors in data displays — every hue must convey operational meaning
|
||||
- Do not use rounded corners > 4px — mission control is functional, not friendly
|
||||
- Do not use proportional fonts for telemetry values — use monospace exclusively for data
|
||||
- Do not animate non-alert elements — motion is reserved for signals that matter
|
||||
- Do not use light mode — low-light environments are the only context
|
||||
- Do not use low-contrast text on dark backgrounds — tertiary `#4A6080` is only for non-critical metadata (timestamps, grid labels)
|
||||
@@ -0,0 +1,85 @@
|
||||
---
|
||||
name: mission-control
|
||||
description: Space/aerospace mission monitoring: dark command center, amber telemetry on navy, monospace precision. Functional clarity above all. For ops dashboards, build/deploy status, and real-time monitoring.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: hand-authored
|
||||
---
|
||||
|
||||
<!-- HAND_AUTHORED_MANAGED_START -->
|
||||
# Mission Control Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Mission Control.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers. This system is hand-authored; treat its DESIGN.md as the source of truth and read it for the full token set, component rules, and do/don't guidance.
|
||||
|
||||
## Brand
|
||||
Mission Control — precise, subdued, mission-critical.
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: themed, information-dense, low-light, high-stakes
|
||||
- Typography fonts: primary=monospace, display=monospace, mono=monospace
|
||||
- Color palette: amber telemetry, navy canvas, cyan healthy, alert red
|
||||
- Key tokens: background=#0B1120, surface=#111827, border=#1E3A5F, primary=#FFB800, accent=#00D4FF, alert=#FF4757, text=#E8F0FE, text-2=#8BA3C7, text-3=#4A6080
|
||||
- Spacing / layout: hierarchical telemetry grid; readable at 3m in low light
|
||||
|
||||
## Accessibility
|
||||
WCAG 2.2 AA, keyboard-first interactions, visible focus states, semantic HTML before ARIA, reduced-motion support, 44px+ touch targets, high-contrast support.
|
||||
|
||||
## Writing Tone
|
||||
precise, subdued, mission-critical
|
||||
|
||||
## Rules: Do
|
||||
- prefer semantic tokens over raw values
|
||||
- preserve visual hierarchy
|
||||
- keep interaction states explicit
|
||||
- read DESIGN.md for the authoritative palette, type, and component rules
|
||||
|
||||
## Rules: Don't
|
||||
- avoid low contrast text
|
||||
- avoid inconsistent spacing rhythm
|
||||
- avoid ambiguous labels
|
||||
- do not invent hex values outside this system's palette
|
||||
|
||||
## 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.
|
||||
|
||||
<!-- HAND_AUTHORED_MANAGED_END -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Modern
|
||||
colors:
|
||||
primary: "#553F83"
|
||||
secondary: "#111111"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#553F83"
|
||||
text: "#ffffff"
|
||||
neutral: "#553F83"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "IBM Plex Serif"
|
||||
fontSize: 2rem
|
||||
body-md:
|
||||
fontFamily: "IBM Plex Serif"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "12/14/16/20/24/32"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Contemporary editorial style with serif typography, minimal palettes, and clean layouts for polished digital products.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** modern, minimal, clean, editorial
|
||||
- **Typography scale:** 12/14/16/20/24/32
|
||||
- **Typography fonts:** primary=IBM Plex Serif, display=IBM Plex Serif, mono=JetBrains Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, secondary
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#553F83):** Token from style foundations.
|
||||
- **Secondary (#111111):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#553F83):** Token from style foundations.
|
||||
- **Text (#ffffff):** Token from style foundations.
|
||||
- **Neutral (#553F83):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
name: modern
|
||||
description: Contemporary editorial style with serif typography, minimal palettes, and clean layouts for polished digital products.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Modern Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Modern .
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
Ship software peacefully
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: modern, minimal, clean, editorial
|
||||
- Typography scale: 12/14/16/20/24/32 | Fonts: primary=IBM Plex Serif, display=IBM Plex Serif, mono=JetBrains Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary, secondary | Tokens: primary=#553F83, secondary=#111111, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#553F83, text=#ffffff
|
||||
- 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
|
||||
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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Mono
|
||||
colors:
|
||||
primary: "#37F712"
|
||||
secondary: "#00A6F4"
|
||||
success: "#00A63D"
|
||||
warning: "#FE9900"
|
||||
danger: "#FF2157"
|
||||
surface: "#E7E5E4"
|
||||
text: "#78716B"
|
||||
neutral: "#E7E5E4"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Space Mono"
|
||||
fontSize: 3rem
|
||||
body-md:
|
||||
fontFamily: "Space Mono"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "desktop-first expressive scale"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "compact density mode"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Monospace-driven, matrix-inspired design with high-contrast elements, compact density, and a hacker-chic aesthetic.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** minimal, clean, high-contrast, playful, matrix
|
||||
- **Typography scale:** desktop-first expressive scale
|
||||
- **Typography fonts:** primary=Space Mono, display=Space Mono, mono=JetBrains Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, secondary, success, warning, danger, info
|
||||
- **Spacing scale:** compact density mode
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#37F712):** Token from style foundations.
|
||||
- **Secondary (#00A6F4):** Token from style foundations.
|
||||
- **Success (#00A63D):** Token from style foundations.
|
||||
- **Warning (#FE9900):** Token from style foundations.
|
||||
- **Danger (#FF2157):** Token from style foundations.
|
||||
- **Surface (#E7E5E4):** Token from style foundations.
|
||||
- **Text (#78716B):** Token from style foundations.
|
||||
- **Neutral (#E7E5E4):** Derived from the surface token for official format compatibility.
|
||||
+88
@@ -0,0 +1,88 @@
|
||||
---
|
||||
name: mono
|
||||
description: Monospace-driven, matrix-inspired design with high-contrast elements, compact density, and a hacker-chic aesthetic.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# mono design Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for mono design.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
Join the private club where people are building, monetizing, and marketing products with AI.
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: minimal, clean, high-contrast, playful, matrix
|
||||
- Typography scale: desktop-first expressive scale | Fonts: primary=Space Mono, display=Space Mono, mono=JetBrains Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary, secondary, success, warning, danger, info | Tokens: primary=#37F712, secondary=#00A6F4, success=#00A63D, warning=#FE9900, danger=#FF2157, surface=#E7E5E4, text=#78716B
|
||||
- Spacing scale: compact density mode
|
||||
|
||||
|
||||
## Accessibility
|
||||
WCAG 2.2 AA, keyboard-first interactions, visible focus states, semantic HTML before ARIA, screen-reader tested labels
|
||||
|
||||
## Writing Tone
|
||||
concise, confident, helpful, clear, friendly
|
||||
|
||||
## Rules: Do
|
||||
- prefer semantic tokens over raw values
|
||||
- preserve visual hierarchy
|
||||
- keep interaction states explicit
|
||||
- design for empty/loading/error states
|
||||
- ensure responsive behavior by default
|
||||
|
||||
## Rules: Don't
|
||||
- avoid low contrast text
|
||||
- avoid inconsistent spacing rhythm
|
||||
- avoid decorative motion without purpose
|
||||
- avoid ambiguous labels
|
||||
- avoid mixing multiple visual metaphors
|
||||
- avoid inaccessible hit areas
|
||||
|
||||
## 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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Neobrutalism
|
||||
colors:
|
||||
primary: "#FDC800"
|
||||
secondary: "#432DD7"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FBFBF9"
|
||||
text: "#1C293C"
|
||||
neutral: "#FBFBF9"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Inter"
|
||||
fontSize: 2.1875rem
|
||||
body-md:
|
||||
fontFamily: "Inter"
|
||||
fontSize: 0.9375rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.8125rem
|
||||
sourceScale: "13/15/17/21/27/35"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Modern take on brutalism with bold borders, vivid accent colors, and raw, high-contrast layouts on warm surfaces.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** modern, clean, high-contrast
|
||||
- **Typography scale:** 13/15/17/21/27/35
|
||||
- **Typography fonts:** primary=Inter, display=Inter, mono=JetBrains Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#FDC800):** Token from style foundations.
|
||||
- **Secondary (#432DD7):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FBFBF9):** Token from style foundations.
|
||||
- **Text (#1C293C):** Token from style foundations.
|
||||
- **Neutral (#FBFBF9):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
name: neobrutalism
|
||||
description: Modern take on brutalism with bold borders, vivid accent colors, and raw, high-contrast layouts on warm surfaces.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# neobrutalism Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for neobrutalism design.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: modern, clean, high-contrast
|
||||
- Typography scale: 13/15/17/21/27/35 | 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=#FDC800, secondary=#432DD7, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#FBFBF9, text=#1C293C
|
||||
- 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
|
||||
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 -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: Neon
|
||||
colors:
|
||||
primary: "#BBF351"
|
||||
secondary: "#00BCFF"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "STIX Two Text"
|
||||
fontSize: 2.5rem
|
||||
body-md:
|
||||
fontFamily: "Roboto"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "Source Code Pro"
|
||||
fontSize: 0.875rem
|
||||
sourceScale: "14/16/18/24/32/40"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Electric neon glow effects with high-contrast color pairings for bold, attention-grabbing interfaces.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** high-contrast
|
||||
- **Typography scale:** 14/16/18/24/32/40
|
||||
- **Typography fonts:** primary=Roboto, display=STIX Two Text, mono=Source Code Pro
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, secondary
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#BBF351):** Token from style foundations.
|
||||
- **Secondary (#00BCFF):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
Loaded 100 of 1089 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user