Get a Design System Build Kit

Return the correct build kit for a design system through one capability-based entry point.

Use target: "react" whenever the host can write files and run a terminal. It returns the shadcn install command and real React components. Use target: "html" only for pure inline canvases or artifacts where npm and a build step are unavailable; it returns the framework-free token and component CSS kit. Use target: "react-native" for a React Native or Expo app and target: "swiftui" for an iOS app, never the react target: each returns this system's stored mobile kit, its own material on native primitives, plus the handoff to the matching guide. Use target: "shopify" when the user is styling a Shopify store or theme; it returns ready-to-write Liquid theme files (a CSS asset with this system's real tokens, snippets, and theme editor sections) plus the mandatory handoff to Better Design's get-shopify-guide MCP tool for documentation and validation.

For target: "html", the returned class contract is mandatory, including inside a host-provided visualization workflow: paste the kit CSS verbatim, keep class="ds" on the artifact root, and keep ds-* component classes on interactive controls. App-specific classes may sit alongside them for layout only; never rename or replace the ds-* classes. Before presenting, inspect the artifact source and revise it if either class="ds" or ds- is absent. Put hover-only CSS inside @media (hover: hover) and (pointer: fine) and never let hover move a control or override its selected/pressed styling.

Inline canvases also inject their own semantic-element colors. Replace APP_ROOT in hostIsolationCssTemplate with the artifact's real root selector and paste it after host/base CSS. Inspect rendered text against its computed background and fix anything below 4.5:1 contrast before presenting. Do not stretch cards to fill the canvas or turn every group into a card or pill.

Reuse the selected design system ID or generated projectId. If none is selected, obtain a design system ID from find-design-system first. A redesign does not authorize changing the selected system or its assigned icons.

For the React target, calling with a designSystemId returns ONE shadcn command that installs every component (globals + all UI primitives) into components/ui/ in one shot. Run that command before writing feature code so the agent has the full component library available.

Pass 'component' only when the user explicitly asks to inspect or customise a specific component's source code. In that mode the tool returns the requested components, a scoped install command, and their source code.

Base UI (@base-ui/react) is the default flavor. BEFORE installing, inspect the user's project: if package.json has any @radix-ui/* dependency (or components/ui already imports @radix-ui), pass 'library: "radix"' to match their existing setup; otherwise use the default Base UI. Both flavors install to the same components/ui/ paths.

Match the requested change

Classify the request as repair, polish, or redesign: restore behavior, refine layout, or rebuild layout and components. Follow the user's scope, not analytics-only tool context. Do not downgrade redesign to polish, expand repair, or turn token export/source inspection into a redesign.

Keep the selected design system and assigned icon family/variant unless the user requests a change. Use exact returned icon names/source, never substitute packs, emoji, or invented SVGs. Inventory sections, components, states and responsive layouts; map requested patterns to real system components and record missing primitives.

Plan structural changes and component adoption before redesigning. Rebuild the requested hierarchy, layout and interactions; token swaps and unused imports do not count. Preserve unrelated behavior, accessibility and production/control boundaries.

Preserve all supplied paragraphs, reviews, offer details, links and disclosures, including collapsed answers and inactive tabs, unless the user requests cuts or rewrites. Require a source-to-render content comparison; investigate every omission, not just section counts. A shortened fixture is not a completed page. Label partial prototypes and never treat their checks as full-page evidence.

Compare before/after renders of the same content and states at the same desktop and mobile widths. Show which planned structural changes and component adoption are visible; verify the selected icons, spacing, hierarchy, and working interactions. Copy and accessibility fixes alone do not complete a redesign. Tool calls, generated files, or a source-only review are not visual evidence. If a baseline or rendered check is unavailable, name the missing evidence and report the redesign as unverified. Keep all existing build, accessibility, hover, comprehension, and review gates.

Explain design trade-offs

Before choosing or changing a design direction, tell the user what each real option gains and loses, which users or team bear the cost, and why you recommend it for this project's known audience, goals, and constraints. Use a short line per option: "Gain: ...; lose: ...; affects: ...; fits because: ...". Load get-ux-principle with topic "tradeoffs" when deeper guidance is needed.

Use the current conversation and project evidence. Label assumptions and predicted effects. Do not invent research, conversion gains, metrics, or project facts. If the user has already chosen, explain the accepted trade-off without reopening the choice. Keep minor edits brief; this adds no approval step and never excuses an accessibility or safety failure.

Put the explanation in the conversation or requested project handoff, not extra product UI copy. Before presenting the result, check that material gains and losses were communicated and report any changed trade-off.

Presentation builds use Open Slide

For any pitch deck, presentation, or slide system in a coding host with filesystem and terminal access, use Open Slide (@open-slide/core) with React slide components as the primary editable source. Do not substitute PowerPoint, Google Slides, Reveal, or a standalone static artifact unless the user explicitly requests a different primary format. Unless the user explicitly requests that format as primary, PPTX and PDF are secondary exports only. If Open Slide is unavailable, add and configure it before authoring the deck.

Pick the build target by capability, not by habit:

• You can write files into a project and run a terminal (Claude Code, Cursor, Devin, Antigravity, an IDE agent, Claude Desktop with filesystem/shell tools, any checked-out repo): call get-design-system-kit with target: "react", run the shadcn install, and build real React components. This is the default for any actual project.

• You are in a pure inline chat canvas with NO file writes and NO terminal (ChatGPT canvas, a Claude.ai chat artifact): call get-design-system-kit with target: "html" and build with the framework-free HTML/CSS kit.

Emitting a single standalone .html file as "the app" when you could run the React install is a bug: it can't import @/components/ui/*, drifts from the registry, and discards the real components.

Whichever target, keep the output tight: build the screens the user actually asked for (one, unless they asked for more) from the system's own components/tokens, don't pad them with bespoke decorative CSS, and keep prose brief. Allow a short gain/loss comparison per material design option; skip long write-ups and trailing follow-up questions.

Component fidelity is pass-fail. Before writing markup, inventory components/ui/* and map every visible pattern to an installed component. Use Sidebar for the primary app shell, Table and its row/cell exports for tabular records, and OnboardingStepper for a dependent flow with more than three steps when those components are installed. A raw <aside>, repeated <div> rows, or a custom progress rail is a failure when the matching component exists. Generated-registry dependency changes are part of the required component install. Treat newly added registry-owned packages as install artifacts, not edits to existing package versions. Preserve every pre-existing dependency version and keep required additions. If the install attempts to change an existing version, report that exact conflict and stop; never silently revert a required addition or replace its component.

Compose the installed Sidebar exports directly, including its header, content, items, groups, and footer when provided. Do not restyle a raw aside to resemble the Sidebar or override its surface, active-state, radius, and type treatment in feature code. A design-system import that is never used does not count.

Typography fidelity is pass-fail. Read the installed font tokens before editing globals.css; preserve their @font-face, @import, or framework font loader, and never leave a var(--font-*) reference undefined. In the rendered app, await document.fonts.ready, inspect the computed font-family on the page and a heading, and confirm the intended family loaded before presenting the screen.

Hierarchy is pass/fail, not polish. Give the first view one P0 task and at most one P1 summary; move P2 history, standings, detailed metadata, and empty-state chrome below it or behind a tab/disclosure. Unless the screen is a dense tool (traces, logs, tables and dashboards) or the user asked for density, fail and simplify any first view with more than three major regions, five immediately visible actions, or 25 visible text fragments. A dense tool keeps its summary stats, its records and the selected record's detail in one view: order them with hierarchy instead of cutting them. Do not make density look compact by shrinking everything: the primary display must be at least 1.5× base UI text, section anchors at least 1.2×, and bold must be reserved for the primary display, section anchors, and active values. Labels are a last resort; remove captions that restate obvious values.

Dashboard quality is pass-fail. Start with the domain page title, one supporting line, and one primary action in the same header group. Preserve this scan order: metrics → records → interpretation. Metric values must dominate their labels. Preserve an explicit overview title and supporting line verbatim when the request or fixture supplies them; an active navigation label is not a substitute for the page h1. Do not rename the overview around its primary action. Supplied interface copy takes precedence over generated-copy length targets; report a conflict instead of silently rewriting the supplied words. Every requested dashboard region must exist in source before rendered review begins. When interpretation prose is not supplied, derive a factual interpretation only from supplied counts and current values; do not infer movement, causation, or status. Keep action or selected-state color for actions and selection; use distinct status colors for positive, warning, destructive, and neutral meaning, always with text or an icon as a second cue. Use an installed Badge or StatCard semantic variant when one exists; never style every rate with text-primary. Never invent a trend or status claim to create color or context. Keep useful count, trend, status, record metadata, and explanatory context instead of flattening every row into the same neutral treatment. Do not show a workflow stepper on an overview or dashboard; the overview is not a workflow step. Start progress only after the user begins the dependent task, and keep it attached to the task screens. When a fixture lists its overview as the first item in a steps array, exclude that overview when counting workflow steps. With three or fewer dependent task screens, use no stepper or progress rail.

Composition is also pass/fail. Keep one visible identity block per level and size a short primary task to its content; a major surface fails when more than one-third of its height is unused after the action. Keep related input, derived value, and submit action together, with the input and button sharing a control height and bottom baseline. Decorative spatial cues stay behind the domain header, never behind controls. Paired flags or logos must be accurate and symmetric; otherwise omit every peer asset rather than drawing placeholders.

The UI copy inside the screen follows the same restraint: short headlines (about 6 words), supporting lines about 15 words and at most one per section, no filler adjectives, no exclamation marks, and no emoji as icons. Every visible text fragment needs one job: context, outcome, next action, real doubt, or legal/security. Do not add template footer, provenance, helper, or slogan copy. If deletion does not hurt meaning, action clarity, safety, compliance, or tone, keep it deleted. Never place an eyebrow, kicker, category, or status label immediately above an h1, h2, or h3; start with the title and put essential context in the supporting line or after the title. Avoid the template shapes (gradient hero with an uppercase eyebrow pill, centered three-card feature grid, left-border callout boxes) unless the user asks. After writing the UI, call get-review-rules. For dashboards, run review-dashboard-structure, check-comprehension, and inspect-spacing, deploy the exact source to a public HTTPS preview, then call finalize-dashboard-review with its URL, the exact source, installed component source, and unchanged fixture. Better Design captures the PNG, visible text, and measured DOM itself at 390, 1440, and 1728, then content-addresses the live deployment. A missing trusted capture, invalid deployment revision, invalid geometry, or hidden fixture field means incomplete. Only a VALID final receipt permits presentation; any later source or deployment edit voids it. For other UI, fix every critical or serious review, comprehension, and spacing finding before presenting. Screenshot desktop and mobile and squint-test each viewport; on a commerce or product page, only the product image, price, and primary CTA may dominate.