skills/superdesign/references/INIT.md

You are performing a **Superdesign Init** — analyzing this repository to build UI context files that Superdesign agent will use for design tasks.

## Output Directory
Write all files to `.superdesign/init/` in the project root.

Init creates repository discovery artifacts only. It does not know the remote project, draft ids, final payload-budgeted context bundle, or extracted project components, so it MUST NOT create `.superdesign/resume.json`. The first successful UI draft/iteration writes that durable state per [RESUME.md](RESUME.md). If a full init is regenerated later, treat existing target resume entries as needing freshness validation before their next generation; preserve their project/draft ids while refreshing only affected context.

## Analysis Steps

### 1. Detect Framework & Component Library
Scan `package.json`, config files (`next.config.*`, `vite.config.*`, `rsbuild.config.*`, `nuxt.config.*`, etc.), and import patterns to determine:
- Framework: React, Vue, Svelte, Angular, etc.
- Meta-framework: Next.js, Nuxt, Remix, Astro, etc.
- Component library: shadcn/ui, Ant Design, MUI, Chakra, Radix, custom, etc.
- CSS approach: Tailwind, CSS Modules, styled-components, vanilla CSS, etc.

### 2. Write `components.md`
Identify the project's shared/reusable UI component directory (e.g., `src/components/ui/`, `components/`, `packages/ui/`).

**IMPORTANT**: Include FULL source code for each component, not just descriptions. Superdesign needs the actual implementation to reproduce accurately.

For each component, include:
- File path
- Component name
- Brief description (1 line)
- Key props if obvious from the export
- **FULL source code** in fenced code blocks

Focus on **shared UI primitives** (Button, Input, Dialog, Card, Select, Checkbox, Table, Tabs, etc.), not page-specific components.

This file should contain the ACTUAL CODE of components, not just a list of names.

### 3. Write `layouts.md`
Find and READ all shared layout components. These are the components that appear on every page or across multiple pages:
- App shell / root layout
- Navigation bar (top nav, bottom nav)
- Sidebar
- Header / top bar
- Footer
- Breadcrumb
- Layout wrappers / HOCs

For each, include:
- File path
- Full source code (copy the entire file content)
- Brief description of what it renders

This is critical — Superdesign needs the actual layout code to reproduce pages accurately.

### 4. Write `routes.md`
Map out the page/route structure:
- For file-based routing (Next.js, Nuxt): list route files and their paths
- For config-based routing (React Router, Vue Router): read the router config
- For each route, include: URL path, component file path, layout used
- Include the FULL router config file if it exists (e.g., `router/index.ts`, `routes.ts`)

For key pages (home, dashboard, main features), include a brief summary of what the page renders.

### 5. Write `theme.md`
Extract the design system / theme tokens. Structure the file in **two parts, in this order**:

**Part 1 — Compact token summary (at the TOP).** A concise, readable digest of the actual values: the color palette (token name → value, incl. `:root` and `.dark`), font families and type scale, spacing scale, border-radius, shadows, and breakpoints. This summary is the budget-friendly context the design flow reaches for first — the PAYLOAD BUDGET rule in [SUPERDESIGN.md](SUPERDESIGN.md) points here to avoid passing a giant `globals.css` whole. Keep it tight enough to pass as context on its own.

**Part 2 — Raw source dumps (BELOW the summary).** The complete raw files in fenced code blocks, for when the full source is needed:
- Full `tailwind.config.ts/js` content (especially `theme.extend`)
- Full `globals.css` / `index.css` content
- Full CSS variable definitions (`:root`, `[data-theme]`, etc.)
- Any theme provider files and design token files

### 6. Write `pages.md`
For each key page/route in the app (home, dashboard, main features — up to 10 pages), build a **complete component dependency tree** by tracing imports recursively.

For each page:
1. Start from the page component file
2. Trace ALL local imports (relative `./Foo`, `../Bar`, alias `@/components/Baz` — skip node_modules)
3. For each import, trace ITS imports recursively
4. Present as an indented tree showing every file the page depends on

Format:
```
## / (Home Page)
Entry: src/app/(home)/home-page.tsx
Dependencies:
- src/components/home-ui/elegant-header.tsx
  - src/components/team/create-team-modal.tsx
- src/components/home-ui/elegant-hero-section.tsx
  - src/components/home-ui/home-hero-input.tsx
  - src/components/home-ui/persona-selector.tsx
  - src/components/home-ui/dev-workflow-view.tsx
  - src/components/home-ui/import-site-modal.tsx
- src/components/home-ui/elegant-project-grid.tsx
  - src/components/home-ui/elegant-project-card.tsx
- src/app/(home)/components/template-browse-section.tsx
  - src/app/(home)/components/template-card.tsx
- src/components/layout/Footer.tsx
```

This tree is the **candidate set** of files to pass as `--context-file` when designing a page — the starting point for context selection. It is not an unconditional include-everything list: apply the PAYLOAD BUDGET rules in [SUPERDESIGN.md](SUPERDESIGN.md) when selecting, so the payload does not 400.

Prioritize the most important/complex pages (home, dashboard, settings, etc.). Skip trivial pages (404, offline, status).

### 7. Write `extractable-components.md`
Catalog UI components from the codebase that **can be extracted** as reusable Superdesign `DraftComponent` entities. These are components that appear on multiple pages or define shared UI patterns (navigation, cards, headers, footers).

Organize by category:

#### Layout Components (appear on most pages)
- NavBar / TopNav / BottomNav
- Sidebar
- Header / AppBar
- Footer
- App Shell / Layout Wrapper

#### Basic Components (used across pages)
- Button variants
- Card components
- Input / Form fields
- Badge / Tag
- Avatar
- Tab components

For each extractable component, include:
- **Name** (PascalCase, e.g., `NavBar`, `HeroSection`)
- **Source file path** (e.g., `src/components/layout/NavBar.tsx`)
- **Category**: `layout` or `basic`
- **Brief description** (1 line)
- **Key props to extract** — ONLY state/navigation props that change per page:
  - Active state: `activeItem`, `currentTab`, `isActive`
  - Navigation URLs: `homeHref`, `searchHref`, `profileHref`
  - Visibility flags: `showNotification`, `showBadge`
  - Dynamic counts: `badgeCount`, `notificationCount`
- **Hardcoded elements** (NOT props): icon names, text labels, CSS classes, image sources

Format:
```
## NavBar
- Source: `src/components/layout/NavBar.tsx`
- Category: layout
- Description: Main top navigation with logo, search, and user menu
- Extractable props: activeItem (string, default: "home"), showNotification (boolean, default: false)
- Hardcoded: Logo SVG, menu items text, icon names, all CSS
```

This file serves as a "menu" — the design workflow reads it to decide which components to extract before generating drafts.

## Format Guidelines
- Use markdown with clear headings
- Include file paths as code spans
- **For `components.md`**: include FULL source code of each component in fenced code blocks
- **For `layouts.md`**: include FULL file contents in fenced code blocks
- **For `theme.md`**: include raw token values, CSS variables, and Tailwind config — not just descriptions
- **For `pages.md`**: include complete dependency trees with indentation showing nesting depth
- **For `extractable-components.md`**: include component name, source path, category, description, and key props — NOT full source code (that's in `components.md` and `layouts.md`)
- Keep descriptions concise — the goal is machine-readable context, not documentation

## Key Principle: INCLUDE ACTUAL CODE
The init files should contain **actual implementation code** (.tsx, .css, .ts), not just documentation or descriptions. Superdesign needs real code to reproduce UI accurately. Be thorough and complete for the key pages and shared UI — but bounded and deduplicated, not padded. These files are the discovery layer; the actual design calls pass only the target page's necessary context under the PAYLOAD BUDGET (see [SUPERDESIGN.md](SUPERDESIGN.md)), so oversized dumps just raise reader/token cost without helping.