Rohobo Design System Readme

I'll start by inspecting the existing project structure to preserve any valid brand/design decisions already in place.

Let me check the existing project for design decisions.

Now let me create the complete design system. First, the directory structure:

Bash
mkdir -p skills/frontend/design-system

Markdown
---
name: rohobo-design-system-readme
description: Explains the skill hierarchy, source of truth, and dependency graph for the ROHOBO/O³ design system. Use when starting any frontend task to determine which skill files to read and in what order.
---

# ROHOBO/O³ Design System — Master Index

No pre-existing design tokens, component library, or brand guide were found in this
project at inspection time. This design system is therefore established here as the
**single source of truth** going forward. Every visual decision in every ROHOBO
surface (web app, O³ AI interface, marketing pages, internal tools) must trace back
to `design-tokens.md`. Nothing below invents a competing system — if a future
inspection finds existing brand assets (logo files, existing Tailwind config,
existing color values in production), those take precedence and this file must be
updated to match, not overridden.

A ₹100Cr+ SaaS company cannot afford a product that looks like it was built by five different teams. Every button, every heading, every spacing value, every icon must come from the same well. This folder is that well.

design-tokens.md          ← ROOT. All raw values (hex, px, rem, ms) live ONLY here.
        │
        ├── design-foundation.md   (principles, hierarchy, grid philosophy)
        ├── colors-surfaces.md     (semantic color usage — imports tokens)
        ├── typography.md          (font usage — imports tokens)
        ├── spacing-layout.md      (spacing/grid usage — imports tokens)
        ├── iconography.md         (icon system — imports tokens)
        │
        ├── buttons-actions.md     ─┐
        ├── forms-inputs.md         │
        ├── cards-panels.md         │  All component skills import from
        ├── tables-data-grid.md     │  tokens + the 5 core skills above.
        ├── navigation.md           │  NEVER define their own raw values.
        ├── modals-drawers.md       │
        ├── dropdowns-menus.md      │
        ├── tabs-filters.md         │
        ├── badges-status.md      ─┘
        │
        ├── feedback-states.md     (states used BY all components above)
        ├── microcopy.md           (voice/tone used BY all components above)
        ├── ai-interface.md        (O³ orb — composes buttons, cards, states, tokens)
        ├── responsive-ui.md       (breakpoint rules applied ACROSS all components)
        │
        └── visual-consistency.md (AUDIT layer — validates everything above)

Rule of inheritance: A skill file may only reference values defined in design-tokens.md. If a skill needs a new value (a new color, a new spacing unit, a new radius), that value must be added to design-tokens.md FIRST, given a semantic name, and only then referenced. No skill file may contain a raw hex code, raw px value (outside the 4px grid), raw font name, or one-off shadow definition.

When given any frontend task, follow this exact reading order. Do not skip steps. Do not improvise values that "look close enough."

1. Read README.md (this file) — understand the hierarchy.
2. Read design-tokens.md — load the canonical values into context.
3. Read design-foundation.md — understand visual hierarchy principles.
4. Read the core skills relevant to the task: typography.md, colors-surfaces.md, spacing-layout.md, iconography.md.
5. Read the component skill(s) needed for the specific task (e.g. building a table → tables-data-grid.md; building a form → forms-inputs.md).
6. Read feedback-states.md if the component has loading/error/empty/success states (almost all do).
7. Read microcopy.md before writing any user-facing text.
8. If the task touches AI/O³ features → read ai-interface.md.
9. Read responsive-ui.md to apply correct mobile/tablet/desktop behavior.
10. Before finishing, run the checklist in visual-consistency.md — verify no new color, font, spacing value, radius, shadow, or icon was invented.

Hard rules for every AI agent

• Never hardcode a hex color, px value, font-family, or shadow. Use the token name (e.g. bg-surface-raised, text-heading-lg, space-4, radius-md).
• Never introduce a new icon that isn't in the canonical icon map in iconography.md. If a needed icon is missing, add it to the map first.
• Never invent new component states. Use the state set defined in feedback-states.md (default, hover, focus, active, disabled, loading, error, empty, success).
• Never write technical/database language in the UI. Follow microcopy.md.
• Every screen must look like it was designed by the same person. If in doubt, copy the pattern from an existing component skill rather than creating a new one.

See the worked example in visual-consistency.md ("Customer CRM page") for the exact skill-reading sequence and output expectations.

• React + Next.js
• Tailwind CSS — configured so every utility class maps to a token, no arbitrary values (bg-[#123456] is forbidden)
• shadcn/ui — used as unstyled/behavioral primitives only; all visual styling overridden to match tokens
• Lucide Icons — canonical icon set, restricted to the map in iconography.md
• Inter — primary typeface, with Tamil-compatible fallback stack (see typography.md)

Any time a new value is needed anywhere in the product, it is added to design-tokens.md with a semantic name and a one-line justification, and then visual-consistency.md's checklist is re-run. This folder is a living system, but it changes in one place at a time — never by silent duplication.

---

Markdown
---
name: design-tokens
description: Defines the canonical, exhaustive set of raw and semantic design values (color, typography, spacing, radius, shadow, motion, z-index) for ROHOBO/O³. Use whenever any other skill or component needs a concrete value — this is the only file allowed to define raw values.
---

# Design Tokens — Single Source of Truth

Purpose: every color, font size, spacing unit, radius, shadow, duration, and
z-index used anywhere in ROHOBO comes from this file. No exceptions.

• Raw values live ONLY here. All other skills reference semantic token names.
• Tailwind config must mirror these tokens exactly (tailwind.config.ts theme.extend should be generated from this file, not the other way around).
• Adding a new token requires: a semantic name, a value, and a one-line reason.
• Never use an arbitrary Tailwind value (p-[13px], text-[15px], #1a2b3c).

1.1 Brand

Rationale: Indigo reads premium/trustworthy for SaaS (Linear/Vercel-adjacent without copying), teal is reserved exclusively for AI/O³ so users always know "teal = AI is involved."

1.2 Neutrals (UI grays — warm-neutral scale, not pure gray)

1.3 Semantic status colors

1.4 Semantic surface tokens (composed from above — components use ONLY these)

Do not use neutral-* or brand-* tokens directly in components — always go through the semantic layer (surface-*, text-*, border-*) so a future rebrand only requires editing this file.

2.1 Font families