Verified against Cursor · 2026-07-14
Turn a pasted design mock into a component that fits your design system
A brief for pasting a screenshot or Figma export into Cursor's chat/Composer that locks the output to your existing component primitives and design tokens instead of a plausible-looking reimplementation from scratch.
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. 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. 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, name it and ask rather than hardcoding a raw hex or pixel value. When done, list any part of the mock you interpreted rather than measured exactly, so it can be checked against the source file.
Customize the highlighted detailsoptional — the prompt above already works
Why this works
Cursor's chat and Composer 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, or what happens on hover — without being told, the model defaults to writing new one-off markup and inline styles that happen to look right in isolation while ignoring every primitive your design system already has. Naming COMPONENT_LIBRARY explicitly turns 'build this' into 'compose this from what already exists,' which is the difference between a component that matches the mock today and one that also matches the rest of the app in six months. 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 without anyone noticing until a design review catches it.
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. Flagged for review: the mock's price text appears to be a slightly darker gray than any existing text-* token in tailwind.config.ts — I 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.1 · 2026-07-14
Changelog
- 2026-07-14 — Initial publish, verified against Cursor 2.1's multimodal chat/Composer 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
