Better Design

Retrieves accessibility (WCAG 2.1), visual design, animation, content, and comprehension review rules for analyzing code. You MUST call this after writing UI code to self-review your output, then fix every critical and serious issue BEFORE presenting the result. ## 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. **Accessibility (WCAG 2.1):** - Critical: Images without alt text, icon buttons without aria-labels, form inputs without labels - Serious: Focus outline removed, missing keyboard handlers, color-only information **Visual Design:** - Layout & Spacing: Inconsistent spacing, overflow issues, z-index conflicts - Typography: Mixed fonts, line-height issues, missing fallbacks - Color & Contrast: Contrast below 4.5:1, missing hover/focus states - Component fidelity: Feature code that bypasses installed Sidebar and Table compositions - Dashboard hierarchy: Verify title → metrics → records → interpretation, preserve supplied overview copy, distinguish action and status colors, reject invented trends, and reject a stepper on a dashboard overview - Serious: Hover outside `@media (hover: hover) and (pointer: fine)`, hover that moves controls, or hover that overrides selected/pressed styling **Animation & Motion:** - Critical: Reduced-motion paths that hide content or prevent completion - Serious: Motion that delays frequent tasks, breaks under repeated input, uses a disconnected origin, or misses frames under representative load - Moderate: Choreography that competes with hierarchy or drifts from the product's motion tokens **Content (generated-UI tells):** - Walls of text, overwritten copy, filler adjectives, emoji used as icons - Ceremonial copy with no user job; run the deletion test before shipping visible text - Awkward headline or subtitle wraps that split complete phrases or leave orphaned words - Microcopy details: pluralization, improvised unit glyphs, empty states without a next action - Template layouts: gradient hero + eyebrow pill, left-border callout boxes - Reward feedback: confirm the outcome, surface proportional user value, and avoid decorative over-reward - Prose tells in shipped paragraphs (hero, about, pricing, changelog, docs): banned words (delve, leverage, robust, cutting-edge, elevate), binary contrasts ("It's not X, it's Y"), throat-clearing and faux-insight openers, colon reveals, puffery and unsourced "experts agree", fake-profound kickers and recap endings, synonym cycling, emoji headings and mid-sentence bold **Comprehension (would someone outside the team understand it?):** - Mom test: insider vocabulary, unexplained acronyms, sentences too long to follow - 15 second test: word count, stacked concepts, competing actions - Screenshot test: missing title, actions that hide their outcome, icon-only controls - Run these against the real copy with `check-comprehension` once the screen exists Use maxTokens to keep responses focused (recommended: 5000–10000).

get-review-rules

Check on a design system generation started with 'create-design-system'. Returns progress while generating, and the live preview URL + the `npx shadcn add` install command once complete. Generation typically takes 1-3 minutes; poll every ~30 seconds until it reports ready. Once ready, ask the user what's next (icon library, install, or build) instead of stopping.

get-design-system-status

Load Better Design's video design-system guidance for building a product demo or promo video in code. Use this before writing a Remotion composition, and while debugging one. It covers the product-demo brief, brand and motion tokens, responsive format profiles, product interactions, captions and accessibility, story and rhythm, layout traps, rendering, and visual review. Start with scaffold: true. It returns a complete brand-aware Remotion project with landscape and vertical compositions, typed Studio props, a shared timeline, product-interaction scene, sourced proof, captions and an optional generated music bed. Then pick the product shots from the video components: AI answer streams, prompt and search typing, terminal sessions, phone and laptop frames, title reveals, captions, logo stings and social proof. get-motion-guide({}) lists them by group; get-motion-guide({ component: "phone-frame" }) returns that component's source, prop defaults, natural length and install command. They are vendored from snapcn (MIT) and served from the Better Design registry, so the shadcn CLI installs them with their dependencies. Install and follow the twelve official Remotion skills from https://www.remotion.dev/docs/ai/skills for current APIs. Better Design owns brand, hierarchy, story, pacing and review. RemotionUI, remocn and Remotion Bits are optional, source-labelled pattern libraries; ask before installing community code and adapt it to the active video tokens. This tool does not render. Rendering needs Remotion and a large headless-browser download in the user's own project. Write the files into their repo and let them run it. This complements the design tools: use get-ui-principle for visual decisions and get-ux-principle for product behavior. For in-app animation whose timing the user should tune by eye (durations, springs, stagger), call get-jig-guide and mount its tuning panel instead of guessing values. You can either: 1. Get the starter project: get-motion-guide({ scaffold: true }) 2. Get one video component as files: get-motion-guide({ component: "answer-stream" }) 3. Request a known topic: get-motion-guide({ topic: "video-design-system" }) 4. Use an alias: get-motion-guide({ topic: "product demo structure" }) 5. Search for the current task or problem: get-motion-guide({ query: "reflow my product demo for vertical video" }) 6. Get the full topic and component index: get-motion-guide({}) Prefer query search when you do not know the topic name. Use maxTokens to keep responses focused (recommended: 5000-10000).

get-motion-guide

Load practical sales guidance before a live conversation or before writing a sales asset. Use this to handle objections, prepare a champion, map features to value, or decide when honesty means recommending a different approach. For objections, load the sales-principles topic and follow ACERS in order: Acknowledge, Clarify, Empathize, Reframe, Sell. You can either: 1. Request a specific topic or alias: get-sales-principle({ topic: "ACERS" }) 2. Search for the situation: get-sales-principle({ query: "help a champion answer an implementation objection" }) 3. Get the index of all sales principles: get-sales-principle({}) Use maxTokens to keep responses focused (recommended: 5000–10000).

get-sales-principle

Load Better Design's Shopify Liquid and Online Store 2.0 implementation guidance directly from the MCP. No separate agent skill is required. Use this before creating or changing Liquid, JSON templates, sections, blocks, snippets, locale files, theme assets, product forms, cart behavior, or Shopify CLI workflows. The guides cover theme architecture, Liquid objects/tags/filters, merchant-editable schema, LiquidDoc, localization, accessibility, performance, validation with Shopify Theme Check, and building a sales page, advertorial, or product landing page on a store's own brand. They link to Shopify's primary documentation for version-sensitive API details. You can either: 1. Request a known topic: get-shopify-guide({ topic: "shopify-theme-architecture" }) 2. Use an alias: get-shopify-guide({ topic: "liquiddoc" }) 3. Search for the current task or error: get-shopify-guide({ query: "product form variant selector and money formatting" }) 4. Get the full topic index: get-shopify-guide({}) Prefer query search when you do not know the topic name. Run Shopify Theme Check after writing files. Use maxTokens to keep responses focused (recommended: 5000-10000).

get-shopify-guide

Load implementation guidance for SwiftUI and native Apple platform work. Use this while planning, building, or debugging a SwiftUI interface. It covers native layout and view composition, animation and gestures, Metal shader effects, and the platform APIs those depend on, with copyable Swift examples. This complements the design tools: use get-ui-principle for visual decisions, get-ux-principle for product behavior, and get-react-native-guide when the target is React Native or Expo rather than native Swift. You can either: 1. Request a known topic: get-swiftui-guide({ topic: "swiftui-ripple-refraction" }) 2. Use an alias: get-swiftui-guide({ topic: "water ripple" }) 3. Search for the current task: get-swiftui-guide({ query: "bend an image where the user touches it" }) 4. Get the full topic index: get-swiftui-guide({}) Prefer query search when you do not know the topic name. Use maxTokens to keep responses focused (recommended: 5000-10000).

get-swiftui-guide

Load visual UI design principles into context on-demand. Use this for visual surface decisions: hierarchy and emphasis, spacing/layout and grouping, typography, color, depth, images, accessibility, polish, and animation. Building a shop, product page, or product imagery: load product-pages and product-imagery. Building a landing or marketing page: load marketing, then also load positioning from get-ux-principle before writing the headline, because what the page says is decided before how it looks. For behavior, flows, forms, navigation, notifications, errors, search, onboarding, microcopy, positioning, rewards, behavior change, design process, or psychology/cognitive laws, use get-ux-principle instead. You can either: 1. Request a specific topic or alias: get-ui-principle({ topic: "spacing" }) 2. Semantic search: get-ui-principle({ query: "group this dense screen with clearer proximity" }) 3. Get index of all principles: get-ui-principle({}) Use maxTokens to keep responses focused (recommended: 5000–10000).

get-ui-principle

Load UX behavior and product-flow principles into context on-demand. Use this before implementing flows or interactive behavior: forms, navigation, notifications, errors, dialogs, search, onboarding, responsive behavior, microcopy, positioning, value proposition, rewards and behavior change, design process and clarity audits, motion briefs, interaction patterns, mobile patterns, sound, anti-patterns, understanding users, and cognitive laws / psychology / behavioral science. Writing a landing page headline, value proposition, or any copy that has to say why a product is worth attention: load positioning first, and ask the user for the answers rather than inventing them. Building a catalog, collection page, or product listing: load commerce-catalog. Building a cart, checkout, or payment step: load commerce-checkout. Building a chat, agent, or near-empty prompt-and-response product, or deciding where brand lives once the chrome is gone: load brand-in-sparse-interfaces. You can either: 1. Request a specific topic: get-ux-principle({ topic: "behavior-change" }) 2. Use an alias: get-ux-principle({ topic: "reward design" }) 3. Semantic search: get-ux-principle({ query: "confirm progress with control, competence, or recognition" }) 4. Get index of all UX principles: get-ux-principle({}) Use maxTokens to keep responses focused (recommended: 5000–10000).

get-ux-principle

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"` when the project is React Native or Expo, never the react target: it returns this system's tokens compiled to a React Native theme, plus the primitives that read it. 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. ## 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, Windsurf, 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 your prose to a line or two, no multi-paragraph write-ups or 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 user explicitly asks for a dense dashboard, fail and simplify any first view with more than three major regions, five immediately visible actions, or 25 visible text fragments. 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.

get-design-system-kit

Return a tuning-panel setup (a "jig") plus the workflow for using it. Call this whenever you are about to hard-code taste-based parameter values: animation duration/easing/springs/stagger, particle systems, canvas physics, blur/glow/grain intensity, gradient stops, shadow recipes, parallax speeds. Instead of guessing values, wire the jig to those parameters, let the USER tune by eye, then hard-code the values they copy back and remove the jig. React web recommends DialKit (MIT, no re-render lag) with a dependency-free fallback; 'vanilla' and 'react-native' get dependency-free scaffolds.

get-jig-guide

Read the user-tuned design config (exact color tokens, radius, fonts, icon library) of a generated project. Call this BEFORE building or restyling UI for the project, and again after the user tunes values on the project page, so you apply their exact numbers instead of guessing from adjectives.

get-design-config

Measure spacing in a rendered interface. Returns a concise text summary and measured findings in structuredContent, without an inline HTML report. Use after UI changes when a browser or DOM evaluator is available. This is the runtime counterpart to get-review-rules. It automatically loads the live visual-design rubric, but it does not guess pixel values from a screenshot. Exact claims come from DOM geometry. Workflow: 1. Call with no states to receive a read-only browser capture script in structuredContent.captureScript. Use detail: "full" if your client reads only text; it includes the script in text. That call measures nothing. 2. Evaluate that script in each rendered state you need to review: at minimum 1440, 1728 and 390 wide. Also capture named hover, focus, selected, and open states when they change a control's surface or layout. 3. Call again with the captured states and the project's spacing scale when known. The layout counts as measured only when this second call returns status `completed`; reading the snapshot yourself is not a measurement. Text shows up to five findings, ordered by severity. Read structuredContent.findings or use detail: "full" for every returned finding, measurement, and fix. Structured evidence retains captured geometry and optional screenshots for report renderers. The capture reads visible layout geometry, computed spacing, corner radii, surface styles, and short accessible labels for interactive controls. It does not collect source code, cookies, form values, or network data. Add data-bd-inspect-label, data-bd-symmetry, data-bd-group, data-bd-compare-size, data-bd-align-group, and data-bd-align-edge attributes when the intended relationship cannot be inferred safely.

inspect-spacing

Fetch SVG icons and return component file contents for the agent to save. This tool does not write files or modify the user's repository. Call this after `find-icons` to materialise the chosen icons as owned, SSR-clean component files, with no runtime CDN fetch from `api.iconify.design` and no first-paint flash. The tool fetches each SVG from the public Iconify API, inlines its viewBox + body into a small `<Name>Icon` React component, and returns a list of `<file path="...">`-tagged blocks for the agent to write to disk. A barrel `index.ts` is also returned. Usage after writing the files: ```tsx import { HomeIcon } from "@/components/icons"; <HomeIcon className="size-4" /> ``` If `components/icons/index.ts` already exists in the project, MERGE the new exports into it rather than overwriting.

install-icons

Show the user a visual preview of a design system from the catalog (use the id from 'find-design-system'). Returns a token-true HTML preview: palette, typography, buttons, card, input, badge, plus a link to the full live showcase. Use this when the user wants to SEE a design system before installing it.

preview-design-system

Deterministically review the source of a dashboard or overview before presenting it. For every dashboard, call this after get-review-rules and before check-comprehension. A prose self-review is not a substitute. Pass the complete page module source, the unchanged fixture, the factual interpretation, and the installed Sidebar, StatCard, and Table source files. Never summarize, reconstruct, or submit only the overview component. The tool derives the overview contract from the fixture. It fails incomplete source, rewritten copy, unsupported claims, weak hierarchy, missing or under-composed installed components, raw aside/table markup, the wrong scan order, action color on every rate, and stepper rails on short flows. FAIL is blocking and returns an MCP tool error. Fix every finding and call the tool again until PASS. Then run check-comprehension and inspect-spacing, and call finalize-dashboard-review. Only its VALID source-bound receipt permits presentation.

review-dashboard-structure

Look at an SVG illustration you drew and get back what is visibly wrong with it. You write SVG blind. This renders it in a real browser and judges it against this project's illustration principles, so you find out that a shape does not close, a part floats unattached, the light comes from two directions, or contents sit outside the container meant to hold them. Use it whenever you have drawn an illustration, before you hand it to anyone. Drawing something worth shipping usually takes 2 or 3 rounds. How to call it: 1. Get the rules first with `get-ui-principle({ topic: "svg-illustration" })` and draw against them. 2. `review-illustration({ svg, intent: "an open inbox tray with letters" })`. Say what the drawing is meant to be, in your own words. 3. Fix what `faults` names, then call again passing `reviewToken` back. Reviewing the same drawing again costs nothing while that token is valid. 4. Stop when `faults` is empty. Markup carrying script, event handlers, remote references, or styles that reach outside the drawing is refused rather than cleaned, so the drawing you fix is the drawing you sent.

review-illustration

Write exact design-token values (colors, radius, fonts, icon library) onto a generated project. Use this when the user states concrete values ("make primary oklch(0.62 0.11 45)", "radius 12px"). It merges over the current config and persists, so the change survives restarts and every later get-design-config returns it. Saved config is publicly readable by anyone with the fragment config URL. For vague direction ("warmer", "more playful"), iterate with the user toward concrete values first; do not invent numbers on their behalf.

set-design-config