rds
Back to Design System

Guidelines

How to use and contribute to the Reba Design System

Workflow
Contribution
Best Practices

Overview

RDS is designed to be used by different roles in the MEINC ecosystem. Whether you're designing screens, vibe-coding with AI, or building production features, these guidelines will help you work effectively with the design system.

For DesignersFor Vibe CodersFor Developers

For Designers

Design with RDS foundations and patterns

Using Foundations & Primitives

Start every design with RDS foundations. This ensures consistency across all MEINC products and reduces handoff friction.

Key practices:

  • Use the defined color tokens (brand, muted, destructive) - never custom hex values
  • Follow the 4px spacing scale (4, 8, 12, 16, 24, 32, 48, 64)
  • Use Geist Sans for UI text, Geist Mono for code
  • Reference existing primitives before creating new elements
View Foundations

Working with Figma

RDS maintains a Figma library that mirrors the code components. Use it as your single source of truth for visual design.

Workflow:

  1. Enable the RDS Figma library in your project
  2. Use component instances, not detached copies
  3. Apply variants that match code props (size, variant)
  4. Document any deviations in the design file
  5. Link Figma frames to Linear tickets for handoff

TODO: Figma library link will be added once published. Contact the design team for early access.

For Vibe Coders

AI-assisted development with RDS

Naming Conventions

Consistent naming helps AI understand and generate correct code.

Components:

PascalCase - VideoEmbed, AudioPlayer

Files:

kebab-case - video-embed.tsx

Props:

camelCase - onTimeUpdate, isPlaying

Types:

PascalCase + Props/State suffix

Folder Structure

RDS components live in a predictable structure.

src/components/
├── primitives/     # Atomic components
│   ├── rds-logo.tsx
│   └── index.ts
├── media/          # Media system
│   ├── video-embed.tsx
│   ├── audio-player.tsx
│   └── index.ts
├── comments/       # Comment system
│   ├── comment-list.tsx
│   └── index.ts
├── docs/           # Doc components
│   └── index.ts
└── index.ts        # Barrel export

Proposing New Components

Before creating a new primitive or pattern:

  1. Check if it exists in shadcn/ui first
  2. Search RDS docs for similar patterns
  3. If truly new, document the use case
  4. Create a draft PR with the component
  5. Add to RDS docs with examples

Tip: When prompting AI, reference existing RDS components for style consistency: "Build this like VideoEmbed"

AI Prompting Best Practices

Good prompts:

  • "Create a track list component using RDS Card and Badge primitives"
  • "Add a form following the pattern in src/components/comments/comment-form.tsx"
  • "Use the same spacing and typography as the Foundations page"

Avoid:

  • ✗"Make it look nice" - too vague, no RDS context
  • ✗"Use blue color" - use token names like "brand" instead
  • ✗"Install a new UI library" - we use shadcn/ui + RDS

For Developers

Using and contributing to RDS in code

Importing RDS Components

Import RDS components from the barrel export for clean imports.

// Preferred: barrel import
import {
  VideoEmbed,
  AudioPlayer,
  CommentList,
  RDSLogo,
} from "@/components/rds";

// Also valid: direct import
import { VideoEmbed } from "@/components/media";

// shadcn/ui components
import { Button } from "@/components/ui/button";
import { Card } from "@/components/ui/card";

Contribution Workflow

Follow this workflow when adding or modifying RDS components:

  1. Create a feature branch from main
  2. Add component in appropriate folder
  3. Export from barrel (index.ts)
  4. Add documentation page in /
  5. Run npx tsc --noEmit
  6. Create PR with description + screenshots

PR Title Format:

feat(rds): add TrackList component

Requesting New Components

Need a component that doesn't exist? Here's how to request it:

  1. Check it doesn't exist in shadcn/ui
  2. Create a Linear ticket with:
    • Use case description
    • Proposed API (props)
    • Example usage code
    • Design reference (if available)
  3. Tag with rds-request
  4. Discuss in #design-system channel

Code Standards

Component Structure

// 1. Imports
import { cn } from "@/lib/utils";
import { Card } from "@/components/ui/card";

// 2. Types
interface MyComponentProps {
  title: string;
  variant?: "default" | "compact";
  className?: string;
}

// 3. Component
export function MyComponent({
  title,
  variant = "default",
  className,
}: MyComponentProps) {
  return (
    <Card className={cn("p-4", className)}>
      {title}
    </Card>
  );
}

Checklist Before PR

  • TypeScript strict mode passes
  • Component is exported from barrel
  • Props are typed (no any)
  • Supports className prop for customization
  • Uses cn() for conditional classes
  • Has JSDoc comment explaining purpose
  • Documentation page added (if new component)

Quick Reference

Key Files

  • src/components/index.ts
  • src/components/ui/*
  • src/app/(rds)/*
  • tailwind.config.ts
  • src/app/globals.css

Useful Commands

  • npx tsc --noEmit
  • npm run dev
  • npx shadcn@latest add [component]

Resources