Conventions for developers implementing Figma designs into the codebase. The goal is consistency and maintainability. Follow these unless there's a strong reason not to.

Structure

1. Use semantic HTML elements (<h1>, <p>, <nav>, <main>, <section>, <article>, <header>, <footer>, <button>, etc.) over generic <div>/<span> wherever the element has a meaningful role
2. Opt for Shadcn components instead of building from scratch. If a Shadcn component covers the use case, use it
3. If a Shadcn component needs customization, extend it via className instead of reimplementing it

Styling

1. Use Tailwind utility classes for all styling
2. Use Tailwind CSS variables for colors (e.g. text-primary, bg-card, etc.) instead of hardcoded values (e.g. text-[#4A90E2], bg-gray-200) whenever possible
   • This ensures the UI responds correctly to theme changes
3. Match spacing, sizing, and typography to Figma using Tailwind's scale. Avoid hardcoded values (p-[13px]) unless the design requires precision that the scale can't express
   • Its okay if the Figma doesn’t exactly match the app
4. Use pre-made font styles in globals.css for all text
5. Use cn() (from lib/utils) to conditionally compose class names

Components

1. Filename matches the component name in PascalCase
2. Keep components focused. If a component is doing too much, split it up
3. Shared/reusable components go in components. Feature-specific components go under their feature directory
4. If you find something reused across pages that should be extracted into a shared component (/components) or a CSS variable (globals.css), inform the team before doing so to stay aligned

Interactivity

1. Loading and error states are required for any component that fetches data
2. Ensure all added layouts work on both desktop and mobile views
3. Whole page should not scroll on any pages. Only internal scroll within cards