|
| 1 | +--- |
| 2 | +name: design-system-colosseum |
| 3 | +description: Creates implementation-ready design-system guidance with tokens, component behavior, and accessibility standards. Use when creating or updating UI rules, component specifications, or design-system documentation. |
| 4 | +--- |
| 5 | + |
| 6 | +<!-- TYPEUI_SH_MANAGED_START --> |
| 7 | + |
| 8 | +# Colosseum |
| 9 | + |
| 10 | +## Mission |
| 11 | +Deliver implementation-ready design-system guidance for Colosseum that can be applied consistently across dashboard web app interfaces. |
| 12 | + |
| 13 | +## Brand |
| 14 | +- Product/brand: Colosseum |
| 15 | +- URL: https://arena.colosseum.org/hackathon |
| 16 | +- Audience: authenticated users and operators |
| 17 | +- Product surface: dashboard web app |
| 18 | + |
| 19 | +## Style Foundations |
| 20 | +- Visual style: structured, accessible, implementation-first |
| 21 | +- Main font style: `font.family.primary=Inter`, `font.family.stack=Inter, Arial, sans-serif`, `font.size.base=16px`, `font.weight.base=400`, `font.lineHeight.base=24px` |
| 22 | +- Typography scale: `font.size.xs=12px`, `font.size.sm=14px`, `font.size.md=16px`, `font.size.lg=18px`, `font.size.xl=20px`, `font.size.2xl=24px` |
| 23 | +- Color palette: `color.text.primary=#a0a0a0`, `color.surface.base=#000000`, `color.text.tertiary=#ededed`, `color.text.inverse=#25d0ab`, `color.surface.muted=#0f0f0f`, `color.surface.raised=#2e2e2e`, `color.surface.strong=#f7f7f7`, `color.border.default=#e5e7eb`, `color.border.strong=#01453d` |
| 24 | +- Spacing scale: `space.1=4px`, `space.2=6px`, `space.3=8px`, `space.4=12px`, `space.5=16px`, `space.6=24px`, `space.7=32px` |
| 25 | +- Radius/shadow/motion tokens: `radius.xs=4px`, `radius.sm=6px` | `shadow.1=rgb(255, 255, 255) 0px 0px 0px 0px, rgba(0, 0, 0, 0) 0px 0px 0px 3px, rgba(0, 0, 0, 0) 0px 0px 0px 0px` | `motion.duration.instant=100ms`, `motion.duration.fast=150ms`, `motion.duration.normal=200ms` |
| 26 | + |
| 27 | +## Accessibility |
| 28 | +- Target: WCAG 2.2 AA |
| 29 | +- Keyboard-first interactions required. |
| 30 | +- Focus-visible rules required. |
| 31 | +- Contrast constraints required. |
| 32 | + |
| 33 | +## Writing Tone |
| 34 | +concise, confident, implementation-focused |
| 35 | + |
| 36 | +## Rules: Do |
| 37 | +- Use semantic tokens, not raw hex values in component guidance. |
| 38 | +- Every component must define required states: default, hover, focus-visible, active, disabled, loading, error. |
| 39 | +- Responsive behavior and edge-case handling should be specified for every component family. |
| 40 | +- Accessibility acceptance criteria must be testable in implementation. |
| 41 | + |
| 42 | +## Rules: Don't |
| 43 | +- Do not allow low-contrast text or hidden focus indicators. |
| 44 | +- Do not introduce one-off spacing or typography exceptions. |
| 45 | +- Do not use ambiguous labels or non-descriptive actions. |
| 46 | + |
| 47 | +## Guideline Authoring Workflow |
| 48 | +1. Restate design intent in one sentence. |
| 49 | +2. Define foundations and tokens. |
| 50 | +3. Define component anatomy, variants, and interactions. |
| 51 | +4. Add accessibility acceptance criteria. |
| 52 | +5. Add anti-patterns and migration notes. |
| 53 | +6. End with QA checklist. |
| 54 | + |
| 55 | +## Required Output Structure |
| 56 | +- Context and goals |
| 57 | +- Design tokens and foundations |
| 58 | +- Component-level rules (anatomy, variants, states, responsive behavior) |
| 59 | +- Accessibility requirements and testable acceptance criteria |
| 60 | +- Content and tone standards with examples |
| 61 | +- Anti-patterns and prohibited implementations |
| 62 | +- QA checklist |
| 63 | + |
| 64 | +## Component Rule Expectations |
| 65 | +- Include keyboard, pointer, and touch behavior. |
| 66 | +- Include spacing and typography token requirements. |
| 67 | +- Include long-content, overflow, and empty-state handling. |
| 68 | + |
| 69 | +## Quality Gates |
| 70 | +- Every non-negotiable rule must use "must". |
| 71 | +- Every recommendation should use "should". |
| 72 | +- Every accessibility rule must be testable in implementation. |
| 73 | +- Prefer system consistency over local visual exceptions. |
| 74 | + |
| 75 | +<!-- TYPEUI_SH_MANAGED_END --> |
0 commit comments