Verified against Cursor · 2026-07-27
Turn a pasted design screenshot into a component built from your existing design system
A brief for pasting a screenshot or Figma export into Cursor's chat or Agent mode that locks the output to your existing component primitives and design tokens, names the interactions a static image can't show, and forces the model to flag anything it interpreted rather than measured.
The prompt
Ready to copy — highlighted parts are example details you can swap.
I'm attaching a design mock (screenshot/image). Build this as a component in this codebase, not a plausible-looking reimplementation from scratch. WHAT THE MOCK SHOWS A pricing card with a plan name, price, a bulleted feature list, and a CTA button, in a 3-column row on desktop. USE THESE EXISTING PRIMITIVES — do not invent new ones or pull in a new UI library Card, Button (variant="primary"), Badge, and the spacing scale in tailwind.config.ts — no other npm UI package. RESPONSIVE BREAKPOINTS TO MATCH Desktop (3-column) at 1024px+, tablet (2-column) at 640-1023px, mobile (1-column, stacked) below 640px. INTERACTIONS NOT VISIBLE IN A STATIC MOCK Hover raises the card with a subtle shadow; clicking the CTA shows a loading spinner in the button for at least 400ms before navigating. ACCESSIBILITY REQUIREMENTS CTA button must be reachable by keyboard tab order, price must have an aria-label including the billing period, and color contrast must meet WCAG AA against the card background. Match spacing, type scale, and color to what's visible in the image as closely as this codebase's existing tokens allow. If an exact match requires a new token or a one-off value not covered by an existing one, name it explicitly and ask rather than hardcoding a raw hex code or pixel value that will drift from the rest of the system the next time it's touched. Compose the component from the primitives listed above wherever they cover what the mock shows. If the mock shows something none of the listed primitives can produce — a layout pattern, a variant, a piece of visual treatment — say so explicitly rather than silently writing custom markup that happens to look right in isolation while bypassing the design system entirely. When done, list every part of the mock you interpreted rather than measured exactly — a color that fell between two existing tokens, a spacing value estimated from the image rather than read from a spec — so it can be checked against the source file by whoever has access to it.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Cursor's chat and Agent mode accept image attachments and reason over them multimodally, but a static image can't convey which of your existing components a given element should map to, what happens on hover, or whether a color is an exact token match or a close approximation — without being told, the model defaults to writing new one-off markup and inline styles that happen to look right against the screenshot in isolation while ignoring every primitive your design system already has, because pixel-matching a flat image is a fundamentally different task from composing from a component library, and nothing in the image itself signals which one it's supposed to be doing. Naming COMPONENT_LIBRARY explicitly turns "build this" into "compose this from what already exists," which is the actual difference between a component that matches the mock today and one that also matches the rest of the app after the next design-token update. ACCESSIBILITY_NOTES exists because a design mock is a visual artifact and structurally cannot encode keyboard behavior, ARIA labeling, or contrast requirements — an agent working from the image alone has no signal that any of that matters unless told, and a component that's visually correct but keyboard-untestable will pass a design review and fail an accessibility audit weeks later. Requiring it to flag any hardcoded value it invented — a one-off hex, a pixel value with no token behind it — surfaces exactly the gap between "looks right against the screenshot" and "fits the actual design system," which is where mock-to-code output usually drifts silently until a design review or a later refactor catches a value nobody remembers adding and nobody can trace back to a decision.
What you get back
Built PricingCard using Card, Button, and Badge from your library. Spacing uses the existing gap-4/gap-6 scale; type uses text-lg/font-semibold for the price, matching your existing Heading styles. CTA button is a native <button> inside Button, keyboard-focusable by default; price span has aria-label="$49 per month". Flagged for review: the mock's price text appears to be a slightly darker gray than any existing text-* token in tailwind.config.ts — used text-slate-700 (closest existing token) rather than inventing a new shade. Please confirm against the source file if exact match matters here. Breakpoints implemented: grid-cols-3 at lg:, grid-cols-2 at sm:, grid-cols-1 below that, per the stated ranges.
Verified against
Cursor 2.2 · 2026-07-27
Changelog
- 2026-07-27 — Initial publish, verified against Cursor 2.2's multimodal chat/Agent-mode image input.
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
