import { Badge } from "@elabs-ai/components-ui";npm install @elabs-ai/components-tokens @elabs-ai/components-uiPrompt for your coding agent
Paste it into Claude Code, Cursor, Codex or any other coding agent. Text in [brackets] is yours to fill in.
Add the brand-ui Badge component (from @elabs-ai/components-ui) to this project. 1. Read https://elabs-ai.com/llms.txt first: it maps every package and the rules. If you can use MCP servers, connect https://elabs-ai.com/mcp and use its search, docs and tokens tools. If not, run the same lookups in the terminal: `npx -y @elabs-ai/components-cli search "<what you need>"` and `npx -y @elabs-ai/components-cli docs <Component>`. 2. Look Badge up before writing code: `npx -y @elabs-ai/components-cli docs Badge` prints its real props, variants, what it pairs with and what to avoid. 3. If @elabs-ai/components-ui is not installed yet: `pnpm add @elabs-ai/components-tokens @elabs-ai/components-ui` (or `npm install @elabs-ai/components-tokens @elabs-ai/components-ui`). If this is the first brand-ui package in the project, wire it once: import `@elabs-ai/components-tokens/styles.css` plus the `themes/light.css` and `themes/dark.css` stylesheets in the CSS entry, add one Tailwind `@source` line per installed @elabs-ai package (Tailwind does not scan node_modules, so without it everything renders unstyled), and wrap the app root in `ThemeProvider` from `@elabs-ai/components-tokens`. 4. Use it here: [the screen or file, and what it should show] 5. Rules: use only @elabs-ai/components-* components and the semantic tokens — no raw colours, no raw font sizes, no arbitrary Tailwind values. Look up each component's real props with the docs tool before you use it; never guess a prop. 6. Done means: the typecheck passes, `npx -y @elabs-ai/components-cli audit src --strict` reports nothing, and you have opened the app and looked at every screen you touched in the light and the dark theme.
Avoid
- Using it to carry an execution status — that is StatusBadge, whose closed seven-state vocabulary pairs a distinct glyph with every tone so the state survives greyscale.
- Using a Badge as a clickable control — use a Button (Badge is not interactive).
- Encoding status by color alone — pair the color with text/icon for non-color users.
Works with
Examples
Statuses
Appearances
The four explicit `appearance` overrides (`tint`/`solid`/`outline`/`neutral`) on every colour-bearing variant — each renders a `data-appearance` attribute and a fixed fill/border/ink recipe regardless of the ancestor `--badge-appearance` token. `secondary`/`outline` are already a neutral pill and an outline respectively, so `appearance` has no additional effect there.
Token Driven Appearance
With no explicit `appearance` prop, an ancestor's `--badge-appearance` token (a theme, or a region wrapper) drives the treatment instead — the badges below carry no `data-appearance` attribute at all.
API
Badge
| Prop | Type | Description |
|---|---|---|
appearance | BadgeAppearance | Explicit per-instance override of the fill/border/ink treatment. Unset (default) renders NO `data-appearance` attribute, so the badge is driven purely by the ancestor `--badge-appearance` token (`auto` = each variant's own recipe, today's look). Meaningful only on the colour-bearing variants (`default`, `success`, `warning`, `destructive`, `info`) — see `badgeVariants`. |