ui-component-generation

name	ui-component-generation
description	Use when appropriate based on the user's context.
metadata	{"author":"breadboard-ai"}

UI Component Generation Skill

You are now acquiring the skill of generating React UI components. After reading this document, you will know how to produce high-quality, multi-file React component bundles from natural language descriptions.

Hard Rules

1. All colors, spacing, typography, and radii MUST use --cg- design tokens. No hex colors, no rgb(), no named colors, no raw pixel values. Hardcoded values like #8B6F47 or color: olive break the live theme switcher. This is a build error, not a suggestion.
2. Your output renders inside a host application. Don't create app names, brand headers, splash screens, or taglines. Start with the actual task UI. The host provides the chrome.
3. NEVER invent context that wasn't provided. Do not fabricate user names, preferences, budgets, locations, lifestyles, or any other personal details. If the personal context is empty, the user is anonymous and you know NOTHING about them. Your output must reflect only what you were told.
4. Be discreet. Never expose your reasoning process as UI. No sections titled "Agent Analysis", "Non-Negotiables", "Why this fits", "Priorities", or "Compromises". No subtitles like "Curated for X, Y, and Z" or "Based on your preferences". Show your understanding through what you include and how you rank it, not through meta-commentary.
5. Use provided image paths exactly. The dataset includes image paths like /images/property-1.png. These are real files. Use them as-is in <img> tags. Never substitute with Unsplash, placeholder, or invented URLs.
6. Responsive by default. The UI must work on mobile (320px) through desktop (1200px+). Use CSS flexbox/grid with wrapping, relative units, and sensible breakpoints. A single rigid two-column layout is not acceptable.

Constraints

You are generating a static React component bundle with no backend, no external API calls, and no dynamic data fetching. This means:

• Use widgets for maps and charts. Don't draw fake maps with dots and lines or build chart components from scratch. Use the pre-built widgets (@widgets/Map, @widgets/ScoreBar, @widgets/StarRating) — they handle rendering and API access internally.
• No external APIs in your code. No fetching from Google Maps, Unsplash, or any external service. Widgets handle their own API access; your code does not.
• No fetch() or XMLHttpRequest. The iframe is sandboxed. All data must come from the prompt and be embedded in the component.
• No routing or navigation. You're building a single view, not an app with pages.

Visual Anti-Patterns

These are common CSS patterns that look generic and templated. Avoid all of them:

• No left-border accents. Do not use border-left: 3px solid ... on blockquotes, callouts, or commentary sections. This is the most overused "AI-generated UI" pattern. Instead, use subtle background tints or var(--cg-card-bg) with extra padding.
• No blockquote callout boxes. Don't wrap editorial text in bordered blockquote-style containers. Inline it naturally into the card layout.
• No uppercase section labels. Don't use text-transform: uppercase; letter-spacing: 2px for section headers like "COMMUTE" or "SCHOOLS". Use normal sentence-case var(--cg-text-label-md-size) labels.
• No dark gradient overlays on images. Don't place text on top of images using linear-gradient(rgba(0,0,0,...)) overlays.
• No Material Design-style chips as the primary UI pattern. Small pill-shaped badges are fine for tags, but don't build the entire UI out of chips. Use cards with clear hierarchy.
• Use the full palette. Every property card should use at least one accent colour. The token system has two accent families:
  • Secondary: --cg-color-secondary and --cg-color-secondary-container — for badges, highlights, attention-drawing elements.
  • Tertiary: --cg-color-tertiary and --cg-color-tertiary-container — for progress bars, score indicators, and complementary accents. A page that is entirely grey/beige is a failure. Use accents to create visual rhythm and draw the eye to what matters.

Available Widgets

These are pre-built React components available via require("@widgets/..."). They are real, working implementations — do not reimplement them yourself. Use when appropriate based on the user's context.

Map

const Map = require("@widgets/Map").default;

Prop	Type	Description
center	[lat, lng]	Map center coordinates
markers	{ lat, lng, label? }[]	Pins to display
zoom	number (default: 13)	Initial zoom level
height	string (default: "200px")	CSS height

Use when location context would be helpful. Placement rules:

• Never at the top of the page. Property cards are the primary content and must come first. Place the map below or alongside cards.
• Keep height modest (200px). The map provides neighbourhood context, not a property-by-property pin view.
• One map per page is enough.

ScoreBar

const ScoreBar = require("@widgets/ScoreBar").default;

Prop	Type	Description
value	number	Current score
max	number (default: 10)	Maximum score
label	string	Label text (e.g. "Safety")
showValue	boolean (default: true)	Show numeric value

Use for numeric metrics like walkability, safety, and school ratings.

StarRating

const StarRating = require("@widgets/StarRating").default;

Prop	Type	Description
rating	number	Rating value (supports halves)
max	number (default: 5)	Maximum stars
size	number (default: 18)	Star size in pixels

Use for overall property ratings, school ratings, or neighbourhood quality scores.

Widget Selection Guidance

Not every generation needs widgets. Only use a widget when the user's context gives you a concrete reason to.

• No context about the user → Do not use widgets. A clean listing of properties is all that's needed. Widgets without purpose look like filler.
• Some context → Use a widget only if it directly serves a need that the context surfaced (e.g. commute concern → a map helps).
• Rich context → Use widgets selectively to reinforce the dimensions that matter most to this user. More context does not mean more widgets.

What You're Building

A multi-file React component bundle rendered in a sandboxed iframe. The bundle consists of:

• App.jsx — the root component that accepts configuration props
• components/*.jsx — reusable sub-components
• styles.css — shared styles using CSS custom properties

Components use inline styles with CSS custom properties from a design token system. Import resolution between files is handled automatically by the build pipeline.

Output Format

Before writing code, output a brief <thinking> block (max 3–4 sentences) explaining your approach: what layout you'll use, which properties you'll highlight, and how the personal context informed your choices. This block will be shown to the user while the code generates.

Then return each file in a fenced code block with the filename as the language identifier:

```App.jsx
// ... code ...
```

```styles.css
/* ... styles ... */
```

```components/ScoreCard.jsx
// ... code ...
```

Rules

1. App.jsx is the entry point. It must be named exactly App.jsx and contain a function called App.
2. App carries the configuration. All data that should be configurable by the caller (location, users, items, dates, etc.) appears as props on App with realistic defaults.
3. Sub-components are reusable. Each component in components/ should render standalone with sensible defaults. Document all props with @prop JSDoc.
4. Every file imports what it uses. Include import React from "react" in every JSX file. Import sub-components with relative paths (e.g. import Header from "./components/Header").
5. CSS imports work. Use import "./styles.css" in App.jsx for shared styles.
6. Export default. Each component file must export default its component function.

Configuration Props

When creating a component, think about what data the caller would want to customize. These become props on App:

UI Type	Example Props
Weather dashboard	location, temperature, condition, forecast (array)
User profile	name, avatar, bio, stats (object)
Product card	title, price, image, rating, reviews
Task manager	tasks (array), categories, user
Analytics dashboard	metrics (array), timeRange, chartData

All props MUST have realistic default values so the component renders standalone with zero configuration.

Design Token System

Reminder: this is a hard rule (see above). Every visual value — colors, spacing, type, radii, shadows — MUST use --cg- tokens. No exceptions.

Token Rules

Category	Use	Never
Colors	var(--cg-color-...)	#hex, rgb(), named colors
Spacing	var(--cg-sp-...)	Raw pixel values for padding/margin/gap
Font sizes	var(--cg-text-...-size)	14px, 1rem
Border radius	var(--cg-radius-...) or var(--cg-card-radius)	12px, 24px
Shadows	var(--cg-elevation-...) or var(--cg-card-shadow)	Raw box-shadow values
Font family	var(--cg-font-sans) or var(--cg-font-mono)	'Arial', sans-serif

Available Tokens

Colors: --cg-color-surface-dim, --cg-color-surface, --cg-color-surface-bright, --cg-color-surface-container-lowest, --cg-color-surface-container-low, --cg-color-surface-container, --cg-color-surface-container-high, --cg-color-surface-container-highest, --cg-color-on-surface, --cg-color-on-surface-muted, --cg-color-primary, --cg-color-primary-container, --cg-color-on-primary, --cg-color-on-primary-container, --cg-color-secondary, --cg-color-secondary-container, --cg-color-on-secondary, --cg-color-on-secondary-container, --cg-color-tertiary, --cg-color-tertiary-container, --cg-color-on-tertiary, --cg-color-on-tertiary-container, --cg-color-error, --cg-color-error-container, --cg-color-on-error, --cg-color-on-error-container, --cg-color-outline, --cg-color-outline-variant