v0.dev Prompt Templates for UI Generation (Now v0.app)

TL;DR: v0.dev now redirects to v0.app, so most v0 dev prompts guides still name a URL that no longer resolves. Vercel publishes its own prompting guidance in two places. The 21 templates below apply it across eight build stages, because a UI prompt has to carry design decisions the generator will otherwise make for you and hand back as finished code.

Is v0.dev still v0.dev?

No. It redirects. Vercel announced the move on 11 August 2025 in a post whose headline reads "v0.dev is now v0.app, the AI builder for everyone", written by Zeb Hermann, GM of v0. Checked on 27 August 2026, https://v0.dev/ returns an HTTP 307 to https://v0.app/, and the redirect preserves the path, so an old v0.dev/chat/<id> bookmark still resolves. The docs moved too: vercel.com/docs/v0 now lands on v0.app/docs.

This matters more than a domain change usually would, because the rename tracks a change in what the product is. The same announcement describes the shift from a UI generator you re-prompted until it looked right into an agent that plans, searches the web, runs commands and fixes its own errors. A lot of the v0 dev prompts content still in circulation was written against the older, narrower product and reads as if v0 returns a single component you paste into a repo.

What does v0 actually build when you prompt it?

Working, deployable applications, not snippets. Vercel's FAQ describes v0 as a platform that turns ideas into production-ready, full-stack web apps, and adds that "It supports popular frontend frameworks and UI libraries, with best-in-class expertise in Next.js, React, Tailwind CSS, shadcn/ui, and the AI SDK."

Those defaults are the single most useful thing to know before writing a prompt, because they are baked in whether you name them or not:

The full-stack docs are blunt about the framework question: "v0 defaults to Next.js, which offers advantages like server actions and API routes for colocating frontend and backend code." The same page adds that "While v0 can use other frameworks, Next.js provides the most reliable results." You can ask for something else. You will spend more prompts getting there.

There are three editing surfaces once code exists, and choosing the wrong one is a common way to burn iterations. There is a full in-browser code editor with diff view, split view and global search. There is Design mode, where you select an element in the live preview and adjust typography, colour, spacing, borders and shadows in a panel, then click Apply to write the change back to source. And there is the prompt itself. Vercel's own guidance on picking between them is one sentence: "Use prompts for logic and structure. Use Design Mode for visual tweaks."

One constraint worth knowing before you plan around it: "Design mode is only available on chats that use the latest preview runtime, and only on the latest version of the chat." It is also unavailable on read-only chats and mobile viewports.

Does Vercel publish its own prompting guide?

Yes, in two places, and they do not say the same thing. Teach both rather than inventing a framework on top.

The documentation page at v0.app/docs/text-prompting opens with a five-step spine: "Start simple. Plan your project. Provide context. Specify and make v0 clarify. Iterate." The rest of the page expands that into advice most people already half-know. Be specific, because "The more specific your prompt, the better the results." Split big builds, because "Large, complex applications are better built incrementally." Name your stack. Ask for error handling explicitly.

The more useful artefact is a Vercel blog post from 15 December 2025, "How to prompt v0", by Esteban Suárez of the v0 DevRel team. It reports that after building applications internally and watching power users, "the best prompts always include three core inputs":

• Product surface — the actual components, data and actions, not a category label
• Context of use — who uses it, when, and what decision they are making
• Constraints & taste — platform, visual tone, layout assumptions

Vercel publishes a fill-in template for those three inputs:

Build [product surface: components, data, actions].

Used by [who],
in [what moment],
to [what decision or outcome].

Constraints:
- platform / device
- visual tone
- layout assumptions

The post's framing of the third input is the line worth memorising: "Constraints tell v0 what not to invent." And on the second: "v0 optimizes for assumed usage. If you don’t define the context of use, it will guess."

Everything below is Vercel's structure. Where I add craft beyond the docs, it is marked as mine.

Why is prompting a UI generator different from prompting ChatGPT?

Because a chat model is allowed to leave things out, and a UI generator is not.

Ask a chat model a vague question and you get a vague answer, which is annoying but honest. Ask a UI generator for "a settings page" and it cannot return something vague. It has to emit running code, which means every unspecified decision gets resolved: a layout, a breakpoint strategy, a focus order, a colour for the destructive action, a shape for the data, and a choice about what the screen looks like when the list is empty or the fetch fails. Those decisions are made silently, at generation time, and then handed to you as finished-looking code.

That is the whole craft difference. Your prompt is not a request. It is a spec that either carries the design decisions or forfeits them. Vercel's own tests found the specific version of a prompt produced fewer lines of code than the vague one, not more, because the model stopped inventing scaffolding nobody asked for. Their conclusion: "Specific constraints make them great while keeping code cleaner."

21 v0 prompt templates, organised by build stage

Copy, replace the bracketed parts, and paste into v0. They are grouped by where you are in a build, because the same information matters at different points. Stages 1 to 3 are Vercel's three-input framework applied. Stages 4 to 8 are the additions I have found matter most and that the docs cover only in passing.

Stage 1: The first component

Start narrower than feels necessary. The docs recommend component-first development for exactly this reason: it is easier to correct one component than to unpick a page.

Build a [component name] with [list the actual sub-elements and data fields, not a category].

Used by [role, technical comfort level],
in [device, environment, time pressure],
to [the one decision this component supports].

Constraints:
- [platform / device]
- [visual tone]
- [layout assumption]

Do not add features I have not listed.

Build a stat card showing: metric label, current value, percentage change vs previous period,
a directional arrow, and a 7-point sparkline.

Used by operations leads (non-technical), glanced at on a wall-mounted dashboard from ~2 metres away,
to spot whether a number moved enough to act on today.

Constraints:
- Desktop, large display, viewed at distance
- High contrast, minimal chrome, no decorative gradients
- Fixed height so a row of these never reflows

Green for improvement, red for decline, neutral grey when change is under 1%.

Build a single [component] and nothing else. No page wrapper, no navigation, no sample page.
Export it as one file with a typed props interface. Props are: [list them with types].
Assume the parent supplies all data. Do not fetch anything inside the component.

Stage 2: The layout scaffold

Layout is the decision that is most expensive to change later, because every subsequent generation inherits it. Fix it before you fill it.

Build the layout shell only: [describe the regions, for example persistent left sidebar,
top bar, scrollable main region, right detail panel].

Fill every region with a labelled placeholder block. No real content, no real data.

Constraints:
- Sidebar [fixed width / collapsible below Xpx]
- Main region is the only scroll container
- Top bar is [sticky / static]
- Maximum content width [X]px, centred

I will fill the regions in later prompts. Keep the file structure obvious so I can point at regions by name.

Convert this layout to a [route group / nested layout] structure using Next.js App Router conventions.
Keep the rendered output identical. List which file now owns which region before you change anything.

Stage 3: A specific screen

This is where the full three-input template earns its keep, because a screen has a job and the job determines the hierarchy.

Build a [screen name] showing: [every section, with the fields in each].

Used by [who], [in what moment], to [what decision or outcome].
They check it [how often] and leave after [what action].

Constraints:
- [device-first choice] and why
- [theme, contrast requirement]
- Colour coding: [rule -> colour, rule -> colour]
- Maximum [N] columns at [breakpoint]

The primary action on this screen is [X]. Everything else is secondary.

Build the same screen again as a second version, optimised for [the opposite context, for example
a first-time user with no data, or a power user with 5,000 rows].
Keep the component vocabulary identical so I can diff the two.

Stage 4: States and edge cases

The most commonly skipped stage and the most commonly regretted one. A generated screen almost always renders the happy path beautifully and the other four states not at all. The docs do tell you to ask: "Add instructions to help clarify behavior, flows, or edge cases."

This screen currently only renders the populated state. Add the other four:

1. Empty (no records yet) - explain why it is empty and give one primary action to fix it
2. Loading - skeleton matching the real layout's dimensions, not a spinner
3. Error (fetch failed) - what went wrong, whether it is retryable, and a retry control
4. Partial (some sections loaded, others still pending)

Render each state from a prop I can toggle so I can review all four without mocking a backend.

Show me every state this component can be in, as a list, before you write any code.
Include states caused by permissions, stale data, and by the user having zero of the thing.
Then implement only the ones I confirm.

Add input-level edge case handling to this form: field-level validation messages tied to inputs
via aria-describedby, a disabled-with-reason submit state, an in-flight submitting state that
cannot be double-submitted, and a success state that does not clear the form until confirmed.
Show the validation rules you inferred so I can correct them.

Assume every string in this component can be 4x longer than the sample data and every list can be
empty or contain 500 items. Fix whatever breaks. Tell me what you changed and why.

Stage 5: Responsive rules

Make it responsive is the phrase that produces a desktop layout that shrinks. Vercel's own comparison found the difference between a basic and a detailed constraint block was exactly this: a shrinking desktop layout versus a genuinely mobile-first one.

Define this component's responsive behaviour at named breakpoints, not by shrinking:

- Under 640px: [what changes structurally - stacking, hiding, collapsing, replacing]
- 640-1024px: [what changes]
- Above 1024px: [what changes]

State which elements are hidden rather than reflowed at each breakpoint, and why hiding is acceptable
for that element. Do not hide anything that carries the primary action.

This layout is currently desktop-first. Rebuild it mobile-first: design the smallest viewport as
the real layout, then add breakpoints upward. The single-column version must be fully usable on its own,
including [the primary task]. Tell me what you had to reorder to make that true.

Stage 6: Accessibility

Vercel's blog lists "Responsiveness or accessibility needs" as part of the constraints input, but the docs do not give you a checklist. This is mine, and it is the block I paste most often.

Audit this component for accessibility and fix what you find. Specifically:

- Semantic elements over div soup; one h1 per page and no skipped heading levels
- Every interactive element reachable and operable by keyboard, in a sensible tab order
- Visible focus indicators that survive the theme
- Accessible names for icon-only controls
- Colour is never the only carrier of meaning - pair it with text or an icon
- Form inputs associated with labels; errors announced, not just coloured
- Contrast at least 4.5:1 for body text against its actual background
- Motion respects prefers-reduced-motion

List what you changed and what you could not fix without a design decision from me.

Walk through this screen as a keyboard-only user and as a screen-reader user, step by step,
and tell me where each one gets stuck or confused. Do not change the code yet.

Stage 7: Theming and the design system

If you have a real design system, v0 has a first-class place to put it. Design Systems 2.0 saves your system as a reusable skill, and the docs are firm about the discipline: "If a component, prop, or token cannot be verified from the sources, v0 should not use it." That is stricter than anything you can enforce from a prompt. If you do not have one imported, these keep a build internally consistent.

Define a token layer for this project before styling anything else:

- Colour: [surface, surface-raised, border, text-primary, text-muted, accent, plus semantic
  success/warning/danger] - as CSS variables consumed by Tailwind, in both light and dark
- Type scale: [N] steps with line heights, one font family for UI and one for numerals if needed
- Spacing scale and one corner-radius value used everywhere
- One elevation ramp of [N] shadow levels

Then restyle the existing components to use only those tokens. Report any hard-coded value you
could not map to a token.

Match the visual language of [describe the reference, or attach a screenshot]: density, corner radius,
border weight, shadow depth, type scale, and how much whitespace separates sections.
Do not copy its content or its colour palette. Apply it to my existing components without changing
their structure or behaviour.

Stage 8: Iterating without wrecking what works

The failure mode here is not a bad generation. It is a good generation that quietly rewrites three things you were happy with. Two mechanics make this manageable, and both are documented.

Versions are automatic: "Each time v0 updates a code block from a message, it creates a new version." Restoring is non-destructive, because "Restoring an old version creates a new, most recent version using the restored code to maintain a linear version history." So you can always get back. The cheaper move is not needing to.

Change only [the specific thing]. Do not modify [list the parts you are happy with by name].
If the change requires touching anything on that list, stop and tell me what and why before editing.

Before you write any code: list the files you intend to change, and for each one, one line on what
changes. Wait for my approval.

That last generation changed more than I asked for. Revert to the previous version, then reapply
only [the one change I wanted], leaving everything else byte-identical.

I want to try three variants of [this element] without touching the rest of the app.
Generate them as three sibling components with the same props interface so I can swap them by
changing one import. Do not modify the parent.

The docs add a structural version of the same idea for full-stack work, listing as a best practice: "Duplicate existing generations to add logic instead of combining UI and logic in a single prompt". Splitting UI from data-layer work into separate chats is the cheapest reliability win available.

Where does generated UI stop being good enough?

At the point where being wrong costs someone something.

Generated UI has a specific failure signature: it looks finished. The spacing is even, the empty states you asked for are there, the dark mode works. That polish is genuinely earned at the presentation layer and it tells you nothing about the layer underneath. A screen that renders a list of invoices perfectly can still be fetching them without an authorisation check.

Vercel's own posture is the right one to copy. The v0 security page states that the team does not take generated code for granted: "We consider all code potentially incorrect or adversarial", and describes analysis and sandboxed execution accordingly. The platform treats its own output as untrusted. So should you.

Three places where the handoff to real engineering is not optional:

Authentication and authorisation. Generated code will produce a login form and route protection that looks right. Session handling, token lifetime, and the server-side check on every data path are the parts that matter, and they are the parts a visual review cannot verify. Read every data-fetching path yourself.

Payments. Anything that moves money needs idempotency, webhook signature verification, and a reconciliation story for the case where the client disconnects mid-flow. Generated flows model the happy path.

Personal data. Two separate questions. First, what your app does with it: retention, deletion, and the server or client boundary. Vercel's docs note that only environment variables prefixed with NEXT_PUBLIC_ are exposed to the browser, and that mistake is easy to make by prompt. Second, what the tool does with your inputs: the published plan comparison lists data opt-out as available on the Business and Enterprise tiers and not below. If you are pasting real customer data into prompts, check which tier you are on first.

The honest framing is that v0 compresses the distance from idea to a working, reviewable artefact, which is a real and large win. It does not compress the review. Pair it with a deliberate read of the generated code, the way you would with any agent output. Our guide to prompting for a genuinely useful code review covers the second half of that loop, and 40 AI prompts for software development covers the surrounding work.

What does the v0 free plan actually let you do?

Enough to evaluate it properly, not enough to build on continuously.

Vercel's pricing documentation lists five plans, with Free described as being for people looking to explore. Free carries a monthly credit allowance and a daily message limit of seven messages, with no team features, no shared projects and no data opt-out. Generation draws down credits, and "When credits are used up, generation pauses." Credits behave like a prepaid balance rather than a rate limit, and "Unused monthly credits roll over to the next billing cycle and expire after 65 days."

The practical consequence for prompting is that vague prompts are literally more expensive than specific ones. Vercel's published comparison of a vague versus a specific prompt for the same profile page found the specific one finished faster, produced fewer lines, and cost less. Iterating your way to a spec costs more than writing the spec.

Figures verified on v0.app/docs/pricing on 27 August 2026. Plans change; check v0.app/pricing before planning around any of them.

Where does a prompt library help here, and where doesn't it?

Honest answer first: Prompt Architects does not generate UI. We generate and manage the prompt. v0 does the building, and nothing in our product makes any individual v0 generation better than a well-written prompt typed by hand.

What a library does change is repetition. Look back at the eight stages. The states block, the responsive block, the accessibility audit block and the scoping block are almost entirely stack-independent. You will paste some version of them into every screen you ever generate, in v0 and in Lovable and in whatever replaces both. Retyping them from memory means a slightly different version every time, which means inconsistent output for reasons you will not be able to trace. That is what a saved prompt template with reusable variables fixes, and it is a bigger effect on a team than solo, because everyone's scaffold is then the same scaffold. We have a longer piece on reusing prompts without copy-pasting if that is the part you care about.

Where it does not help, plainly:

• It cannot see your repo, your preview or your design tokens. v0's Design Systems 2.0 and Instructions can, and for anything v0-specific they are the better home. Use them.
• It does not review generated code, run it, or catch an authorisation hole.
• It will not rescue a prompt that omits the product surface. Vercel's three inputs are the substance; a library is storage for them.

Use both, and put each rule where it belongs. Rules that apply to every v0 generation you will ever run belong in v0 Instructions. Rules that follow you across tools belong in a library.

The short version

The name is v0, the URL is v0.app, and v0.dev redirects. The defaults are Next.js, Tailwind and shadcn/ui whether you name them or not. Vercel publishes a real three-input framework, so use theirs rather than inventing one. And the single behavioural change that improves output most is deciding the seven things a generator would otherwise decide for you: layout, empty, loading, error, responsive, accessible, and the shape of the data. Everything after that is iteration discipline.