What Are UI Prompts and How Do You Use Them With AI Coding Agents?

Updated

A UI prompt is a reusable instruction block that tells an AI coding agent what front-end component to build and how it should look, behave, and handle data. Use one when you want a repeatable component (a chart, a loading skeleton, a toast stack) rather than a one-off screen, and pair it with an agent config file so the output matches your project's tokens and conventions instead of the agent's defaults.

What a UI prompt actually contains

A UI prompt is not a vague request like "make a dashboard." It is a spec the agent can execute without guessing. The parts that matter:

  • Component type — chart, table, modal, toast stack, skeleton screen. Name the exact element.
  • Layout — where it sits, how it sizes, what wraps it.
  • States — loading, empty, error, success, disabled. Agents skip these unless told.
  • Data shape — the fields, types, and ranges the component must handle.
  • Styling constraints — which tokens, framework, or utility classes to use.
  • Accessibility — roles, labels, keyboard behavior, contrast requirements.

If a prompt omits states or data shape, the agent invents them, and you get a component that looks right in a demo and breaks on real input.

Anatomy of a UI prompt

A workable structure, in order:

  1. Role and target — "Build a React component for…"
  2. Component and scope — one component per prompt. Splitting beats one giant prompt.
  3. Data contract — props, types, expected values.
  4. Visual spec — layout, spacing, tokens, responsive behavior.
  5. States — enumerate every one, including empty and error.
  6. Accessibility — ARIA roles, focus order, contrast floor.
  7. Constraints — what not to do (no inline styles, no new dependencies).

The last item is underused. Telling the agent what to avoid prevents it from pulling in a charting library you did not ask for.

Examples from the Design.dev prompt library

Design.dev's AI Prompt Library lists component prompts you can start from, including:

  • UI Component Real-Time Data Chart — a chart that updates from a live data source, which forces you to specify the data contract and update cadence.
  • UI Component Skeleton Loading Screen — a loading state, which only works if the prompt defines the shape of the content being loaded.
  • UI Component Toast Notification Stack — a queue with stacking, dismissal, and timing behavior.

Each of these is a component with states and data, not a page. That is the pattern to copy: prompt for the component, let the agent compose pages from components.

Pair UI prompts with agent config files

A UI prompt describes one component. An agent config file describes the project the component lives in. Design.dev's AI Agent Config Generators produce several of these:

Generator Output What it controls
DESIGN.md Generator DESIGN.md Design tokens and rules agents apply
Design Tokens Generator tokens.css Brand or Figma converted to CSS and Tailwind tokens
AGENTS.md Generator AGENTS.md One config file for every coding agent
Cursor Rules .cursor/rules/*.mdc Scoped rules for Cursor IDE
CLAUDE.md Generator CLAUDE.md Project memory for Claude Code
Copilot Instructions copilot-instructions.md Repo-wide rules for GitHub Copilot
SKILL.md Generator SKILL.md Reusable skills for 27+ coding agents
MCP Config Generator mcp.json Connects agents to tools and data via MCP

The division of labor: the config file carries tokens, conventions, and constraints that apply everywhere; the UI prompt carries the spec for the one component you are building now. Without the config file, every UI prompt has to restate your color scale and spacing, and the agent still drifts.

If you are unsure which config file to use, the choice depends on your agent: Cursor reads .mdc rules, Claude Code reads CLAUDE.md, Copilot reads copilot-instructions.md, and AGENTS.md is the cross-agent option.

Common failure modes

Agents ship predictable problems when prompts are thin:

  • Low-contrast grays — the default palette agents reach for often fails contrast. Design.dev's Color Contrast Checker exists specifically to catch this.
  • Missing states — no empty state, no error state, no loading state. The prompt has to name them.
  • Unstyled defaults — the agent ships browser-default form controls and tables. Styling constraints in the prompt or tokens in the config file fix this.
  • Features that do not ship — the agent writes CSS or JS that your target browsers do not support. Browser Feature Detection confirms what actually ships.
  • Heavy generated images — agent-generated assets arrive uncompressed. The Image Optimizer compresses and converts them before they ship.

How to verify what the agent shipped

Do not trust the diff. Check the output against the prompt:

  1. Contrast — run the shipped colors through a contrast checker, not your eyes.
  2. Feature support — confirm the CSS and JS the agent used actually ships in your target browsers.
  3. States — trigger loading, empty, error, and success manually.
  4. Assets — compress and convert any generated images before they reach production.

Design.dev groups these under "Check What the Agent Shipped," which is the right mental model: the prompt is the input, verification is the other half of the loop.

A practical workflow

  1. Write or generate your agent config file (DESIGN.md, AGENTS.md, or the file your agent reads) so tokens and rules are fixed.
  2. Pick or write a UI prompt for one component, with data contract, states, and accessibility spelled out.
  3. Run the agent and review the diff against the prompt, not against your hopes.
  4. Verify contrast, feature support, states, and assets.
  5. Save the prompt that worked. Reusable prompts are the point — the next component starts from a known-good spec.

Design.dev offers these generators and prompts as free tools, with a weekly newsletter (read by 9,000+ developers per the site) that includes a free pack of 300 icons. The site lists a subscribe option; check the current page for what any subscription includes rather than assuming terms.