These are skeletons, not finished prompts: copy one into the v0 chat box, replace every [BRACKETED PLACEHOLDER] with your specifics, delete the lines you do not need, and send. Each one is built on v0's real prompt structure — product surface (the exact components, data, and actions), context of use (who uses it, in what moment, to make what decision), and constraints & taste (platform, tone, layout, and precise design tokens) — and names the stack v0 actually emits: Next.js App Router, Tailwind CSS, and shadcn/ui.
Filling brackets tightly matters because every v0 generation burns credits even when it misses, so a specific prompt is a cheaper prompt. For paste-ready examples see the 40 best v0 prompts; for the structure behind these skeletons, read how to prompt v0 for UI, and keep the v0 prompt cheat sheet open for tokens and modifiers.
Landing pages
Landing-page prompts work best when you name every section in order and pin exact design tokens, then state what to leave out. Run these as a first message, and iterate section by section afterward.
1. Hero + sections landing page
Build a marketing landing page for [PRODUCT_NAME], a [ONE-LINE PRODUCT DESCRIPTION].
Sections in this order:
1. Sticky header: logo, links to [NAV_ITEMS], and a [PRIMARY_CTA] button.
2. Hero: headline "[HEADLINE]", subhead "[SUBHEAD]", primary + secondary CTA, and [IMAGE / PRODUCT SCREENSHOT PLACEHOLDER].
3. [SECTION_3, e.g. logo cloud / social proof].
4. Features: [FEATURE_1], [FEATURE_2], [FEATURE_3] as cards with icon, title, one line.
5. [PRICING / TESTIMONIALS / FAQ].
6. Footer with [FOOTER_LINKS].
Used by [VISITOR TYPE] deciding whether to [SIGN UP / BOOK A DEMO].
Constraints:
- Next.js App Router, Tailwind, shadcn/ui.
- Design tokens: primary [#HEX], background [#HEX], radius [e.g. 0.75rem], font weight for headings [700], generous spacing.
- Visual tone: [e.g. clean, modern SaaS].
- Responsive down to 360px. Do not add auth or a dark-mode toggle yet.How to use: put your product, section list, CTA labels, and hex/radius tokens in the brackets; delete any section you do not want.
2. Waitlist / coming-soon page
Build a single-screen coming-soon page for [PRODUCT_NAME].
Product surface: centered logo, headline "[HEADLINE]", one-line pitch "[PITCH]", an email capture input with a [BUTTON_LABEL] button, and a small "[TRUST LINE, e.g. No spam, launching Q4]".
Used by [AUDIENCE] who just clicked a link and will decide in seconds whether to join.
Constraints:
- Next.js App Router, Tailwind, shadcn/ui, one page, no scrolling on desktop.
- Tokens: accent [#HEX], background gradient from [#HEX] to [#HEX], radius [VALUE].
- Add a success state after submit ("[THANK-YOU MESSAGE]"). Client-side only for now; do not wire a database.How to use: fill headline, pitch, and button label; set the two gradient hex values and the accent token.
3. Feature / product detail page
Build a feature detail page for [FEATURE_NAME] within [PRODUCT_NAME].
Product surface: a breadcrumb, a hero with the feature name and a [DEMO IMAGE PLACEHOLDER], an "How it works" three-step row ([STEP_1], [STEP_2], [STEP_3]), a benefits grid ([BENEFIT_1]..[BENEFIT_4]), a comparison or "before/after" block, and a closing CTA to [ACTION].
Used by [EVALUATOR] comparing tools, deciding if this feature covers their [USE CASE].
Constraints: Next.js App Router, Tailwind, shadcn/ui. Tokens: primary [#HEX], muted text [#HEX], radius [VALUE], section padding [VALUE]. Keep copy tight and scannable. No pricing table on this page.How to use: name the feature, the three how-it-works steps, and four benefits; leave the image placeholders for v0 to stub.
Dashboards & admin
Dashboards fail when the prompt says "a dashboard" instead of naming the actual metrics and tables. Spell out every KPI, chart, and column, and describe the decision the viewer makes.
4. Analytics dashboard
Build an analytics dashboard for [PRODUCT / TEAM].
Product surface:
- Top KPI row: [METRIC_1], [METRIC_2], [METRIC_3], [METRIC_4], each with value, label, and % change vs [PERIOD].
- A [LINE / AREA] chart of [PRIMARY_METRIC] over [TIME RANGE], with a range selector ([7d / 30d / 90d]).
- A [BAR / DONUT] chart of [BREAKDOWN, e.g. traffic by source].
- A table of [ENTITY, e.g. recent orders] with columns [COL_1], [COL_2], [COL_3] and status badges.
- Left sidebar nav: [NAV_ITEMS].
Used by [ROLE] each morning to decide [WHAT ACTION, e.g. where to spend budget].
Constraints: Next.js App Router, Tailwind, shadcn/ui, use recharts for charts. Tokens: primary [#HEX], positive [#HEX], negative [#HEX], radius [VALUE], compact spacing. Use realistic placeholder data. Responsive; sidebar collapses on mobile.How to use: list your four KPIs, the two chart types and their data, and the table columns; state the daily decision the role makes.
5. Admin CRUD table + detail
Build an admin panel to manage [ENTITY, e.g. users].
Product surface:
- A data table of [ENTITY] with columns [COL_1], [COL_2], [COL_3], [STATUS], and a row actions menu (View, Edit, [DELETE / SUSPEND]).
- Search by [FIELD], filter by [FILTER_FIELD], and pagination.
- A "New [ENTITY]" button opening a form with fields [FIELD_1: type], [FIELD_2: type], [FIELD_3: type].
- Clicking a row opens a detail drawer showing [DETAIL_FIELDS] and an activity list.
Used by [ADMIN ROLE] to keep [ENTITY] data correct and act on problems.
Constraints: Next.js App Router, Tailwind, shadcn/ui (Table, Dialog, DropdownMenu). Tokens: primary [#HEX], radius [VALUE], dense table rows. Mock the data for now; do not wire a database yet.How to use: name the entity, its columns, and the form fields with types; keep the "no database yet" line until you are ready to wire it.
6. Settings / account page
Build a settings page for [PRODUCT_NAME] with a left tab rail.
Tabs and their fields:
- Profile: [NAME], [EMAIL], [AVATAR UPLOAD].
- [WORKSPACE / TEAM]: [FIELDS].
- Notifications: toggles for [NOTIF_1], [NOTIF_2], [NOTIF_3].
- Billing: current plan [PLAN], usage meter for [METRIC], and a [MANAGE / UPGRADE] button.
- Danger zone: [DELETE ACCOUNT] with a confirm dialog.
Used by [ROLE] to configure their account without support.
Constraints: Next.js App Router, Tailwind, shadcn/ui (Tabs, Switch, Card). Tokens: primary [#HEX], destructive [#HEX], radius [VALUE]. Show unsaved-changes state and a save button per section. UI only for now.How to use: fill the tab list and the fields per tab; drop any tab you do not need and keep the danger-zone confirm dialog.
Single components
For one component, give v0 the props, states, and the sibling it should match. Ask it to isolate the component and not wire it into a page, so you can drop it in yourself.
7. Reusable UI component
Create a single [COMPONENT_TYPE, e.g. pricing card] component named [COMPONENT_NAME].
Props: [PROP_1: type], [PROP_2: type], [PROP_3: type].
States: [DEFAULT], [HOVER], [SELECTED / DISABLED], [LOADING].
Behavior: [WHAT IT RENDERS AND DOES ON INTERACTION].
Constraints: Next.js + Tailwind + shadcn/ui, TypeScript, fully typed props. Tokens: primary [#HEX], radius [VALUE], font weight [VALUE]. Accessible (keyboard focus, aria labels). Responsive.
Render it standalone with 2-3 example instances; do not wire it into any page.How to use: list props with types and every visual state; the "standalone, do not wire in" line keeps it a clean, droppable unit.
8. Complex interactive widget
Build a [WIDGET, e.g. multi-step wizard / date-range picker / kanban board] component.
Product surface: [DESCRIBE THE PARTS, e.g. three steps: details, options, review; a progress bar; back/next buttons].
Interactions: [WHAT HAPPENS ON EACH ACTION, e.g. next validates the current step; review shows a summary].
Data shape it works with: [DESCRIBE OBJECT / ARRAY].
Constraints: Next.js + Tailwind + shadcn/ui, TypeScript, manage state locally with [useState / useReducer]. Tokens: primary [#HEX], radius [VALUE]. Keyboard accessible. Include a small demo with mock data. No backend calls.How to use: describe the parts, the per-action behavior, and the data shape; name the state approach so v0 does not over-engineer.
9. Match-an-existing-component
Create a [NEW_COMPONENT] that visually and structurally matches this reference.
[ATTACH A SCREENSHOT of the existing component, OR paste its code below.]
Match the reference's spacing, radius, typography, and color usage exactly. It should accept props [PROP_1], [PROP_2] and support states [STATE_1], [STATE_2].
Constraints: Next.js + Tailwind + shadcn/ui, TypeScript. Do not invent a new visual style; extend the one shown. Render standalone with example data.How to use: attach a screenshot (v0 accepts image references) or paste the sibling's code, then list the props and states the new one needs.
Full-stack CRUD apps
The new v0 runs a sandbox that mirrors a real environment and can wire server actions, route handlers, and a database. Name the entity, its fields, and the actions, and let v0 scaffold schema plus UI together.
10. Plan-first PRD (run before a big build)
Before building anything, write a short PRD for [APP_NAME], a [ONE-LINE DESCRIPTION].
Cover:
- Core entities and their fields: [ENTITY_1 with fields], [ENTITY_2 with fields].
- Main user flows: [FLOW_1], [FLOW_2], [FLOW_3].
- Pages/routes needed and what each does.
- Data + server actions required (CRUD for which entities).
- Out of scope for v1: [WHAT TO SKIP].
Then list the files you would create, in build order. Do NOT write code yet — wait for me to approve the plan.How to use: describe the app, its entities and flows; approve or edit the plan before you let v0 generate, then queue the build steps.
11. Full-stack CRUD app with database
Build a full-stack [APP_NAME] where users can [CORE ACTION, e.g. create and track projects].
Entity: [ENTITY] with fields [FIELD_1: type], [FIELD_2: type], [FIELD_3: type], [STATUS: enum].
Pages:
- List page: table/cards of [ENTITY] with search, filter by [FIELD], and a create button.
- Detail page: view and edit one [ENTITY].
- Create/edit form with validation on [REQUIRED_FIELDS].
Wire it end to end:
- Use [Supabase / Neon / Postgres] for storage; create the [ENTITY] schema.
- Implement create, read, update, delete via server actions (Next.js App Router).
- Validate input with [zod] and show inline errors.
Constraints: Tailwind + shadcn/ui. Tokens: primary [#HEX], radius [VALUE]. Optimistic UI on create/delete. When it works, prepare it to deploy to Vercel.How to use: define one entity fully with field types, then let v0 generate the schema, server actions, and pages; swap the database name to your provider.
12. Import-and-extend an existing repo
Import my repo [GITHUB_REPO or connect via GitHub] and add [FEATURE].
First, read the existing code and tell me: the framework/stack in use, where [RELEVANT_AREA] lives, and the patterns I use for [components / data fetching / styling].
Then add [FEATURE] by:
- [WHAT TO BUILD, in terms of the product surface].
- Matching my existing conventions for [NAMING / FOLDER STRUCTURE / DESIGN TOKENS] — do not introduce a new style.
- Touching only [ALLOWED_PATHS]; leave [DO-NOT-TOUCH_PATHS] alone.
When done, open a pull request with a summary of the change.How to use: point v0 at your GitHub repo, name the feature and the paths it may touch; the "match my conventions" line keeps the diff consistent.
Auth & forms
Auth and forms live or die on validation and states. Name every field, its rules, and the empty/loading/error/success states so v0 builds the full lifecycle, not just the happy path.
13. Auth screens (sign in / sign up)
Build sign-in and sign-up screens for [PRODUCT_NAME].
Product surface:
- Sign in: [EMAIL] + [PASSWORD], "remember me", forgot-password link, and [OAUTH PROVIDERS, e.g. Google, GitHub] buttons.
- Sign up: [NAME], [EMAIL], [PASSWORD] with a strength hint, and a terms checkbox.
- Shared: brand panel on one side, form on the other; inline validation; loading and error states.
Constraints: Next.js App Router, Tailwind, shadcn/ui (Form, Input, Button). Tokens: primary [#HEX], radius [VALUE]. Validate with [zod]. Wire auth with [Supabase Auth / NextAuth] and protect [PROTECTED_ROUTES]. Responsive; single column on mobile.How to use: list the fields and OAuth providers, then name the auth library and the routes to protect; drop the OAuth line if you want email-only.
14. Multi-field form with validation
Build a [FORM_NAME, e.g. onboarding / checkout / application] form.
Fields (with rules):
- [FIELD_1]: [type], [required?], [validation rule].
- [FIELD_2]: [type], [required?], [validation rule].
- [FIELD_3]: [select / radio] with options [OPTIONS].
- [FIELD_4]: [file upload / date / textarea].
Behavior: inline validation on blur, a disabled submit until valid, a loading state on submit, and a success screen "[SUCCESS MESSAGE]".
Constraints: Next.js App Router, Tailwind, shadcn/ui + react-hook-form + zod. On submit, call a server action [ACTION_NAME] that [WHAT IT SAVES]. Tokens: primary [#HEX], radius [VALUE]. Accessible labels and error text.How to use: list each field with its type and validation rule; name the server action and what it persists, or delete that line for a UI-only form.
15. Search + filter interface
Build a search and filter interface for [ITEM_TYPE, e.g. listings].
Product surface:
- A search input (searches [SEARCHABLE_FIELDS]).
- Filters: [FILTER_1: type, e.g. category select], [FILTER_2: price range slider], [FILTER_3: toggle].
- A results grid/list of [ITEM] cards showing [CARD_FIELDS], with sort by [SORT_OPTIONS].
- Empty state, loading skeletons, and a "clear all filters" control.
Used by [USER] narrowing down to the right [ITEM] fast.
Constraints: Next.js App Router, Tailwind, shadcn/ui. Reflect filters in the URL query params. Tokens: primary [#HEX], radius [VALUE]. Mock [N] results for now. Responsive grid.How to use: name the item type, the searchable fields, and each filter with its control type; keep the URL-params line for shareable filtered views.
Iteration & Design Mode
After the first generation, iterate two ways: prompt for changes for functional edits and layout, and Design Mode (v0's visual editor) for quick color, spacing, and typography polish. Queue up to about ten sequential change requests to work through a list in order.
16. Prompt-for-changes (functional edit)
Change the current [SCREEN / COMPONENT]:
- [CHANGE_1, e.g. move the CTA above the fold].
- [CHANGE_2, e.g. add a [FIELD] to the form and validate it].
- [CHANGE_3, e.g. replace the bar chart with a line chart].
Keep everything else exactly as it is — do not restyle or remove anything I did not mention. Preserve the current design tokens and layout. Show me only what changed.How to use: list only the functional edits you want; the "keep everything else" line stops v0 from redesigning working sections.
17. Queued change list
Work through these changes in order, one at a time, confirming each before the next:
1. [CHANGE_1].
2. [CHANGE_2].
3. [CHANGE_3].
4. [CHANGE_4].
5. [CHANGE_5].
Do not batch them or add anything not on the list. Keep the existing tokens and structure between steps.How to use: drop up to about ten sequential steps so v0 queues them; number them in the order you want the work done.
18. Design-token / Design Mode adjustment
Apply these design tokens across the whole UI (visual only, no layout or logic changes):
- Primary: [#HEX] - Secondary/accent: [#HEX]
- Background: [#HEX] - Foreground/text: [#HEX]
- Muted: [#HEX] - Border: [#HEX]
- Radius: [VALUE] - Base spacing scale: [e.g. 4px]
- Heading font weight: [VALUE] - Body: [VALUE]
- Density: [comfortable / compact]
Update the Tailwind theme / CSS variables so these are reused everywhere, not hard-coded per component. Keep all existing content and structure. For finer tweaks I will switch to Design Mode.How to use: fill the full token set once so v0 wires them into the theme; use this for a rebrand, then reach for Design Mode's visual editor for per-element nudges.
Frequently Asked Questions
How do I use these v0 prompt templates?
Copy a skeleton into the v0 chat box, replace every [BRACKETED PLACEHOLDER] with your specifics (product surface, users, design tokens), delete lines you do not need, then send. Each template already follows v0's product-surface plus context plus constraints structure and names the real stack (Next.js App Router, Tailwind, shadcn/ui), so you only fill the blanks.
Why do the templates repeat design tokens?
v0 emits real Tailwind and shadcn/ui code, so exact tokens (brand color, radius, font weights, spacing scale) are the difference between generic output and something that matches your product. Stating tokens once in the prompt means fewer follow-up rounds and fewer wasted credits, since every generation, even a failed one, burns credits.
Should I ask for a plan or PRD before v0 builds?
For anything larger than a single component, yes. Use the plan-first template so v0 writes a short PRD and file list you can approve before it generates. This catches wrong assumptions cheaply and pairs well with prompt queuing, where you chain up to about ten sequential build steps. See how to prompt v0 for UI for the full workflow.
What is the difference between prompting for changes and Design Mode?
Prompt for changes when you need functional edits: new features, restructured layout, wired data. Use Design Mode, v0's visual editor, for quick visual polish like colors, spacing, typography, and toggling component states without writing code. The iteration templates above cover both paths.
Can v0 build full-stack apps with a database?
Yes. The new v0 runs a sandbox that mirrors a real environment and can wire server actions, route handlers, and databases like Supabase, Neon, or Postgres, plus auth and environment variables. The full-stack CRUD templates state the entity, fields, and actions so v0 scaffolds the schema, server actions, and UI together, then deploys to Vercel.
Can I use these on an existing codebase?
Yes. The new v0 supports native GitHub integration and importing an existing repo, so it can create a branch, open a pull request, and push from chat. The import-and-extend template tells v0 to read your current patterns first and match them instead of introducing a new style.
How do I stop v0 from adding things I did not ask for?
State what NOT to build. Every template leaves a Do not line for constraints like no auth yet, no dark-mode toggle, or no extra pages. Being explicit about scope keeps generations focused, cheaper in credits, and closer to what you actually want on the first try. The best v0 prompts roundup shows this in finished examples.
Do the templates depend on a paid v0 plan?
No. They are model- and tier-agnostic. v0 has a free tier with monthly credits and a small daily message cap, plus Premium, Team, Business, and Enterprise. Prompting technique matters more than tier, and a tight, specific prompt is what saves credits regardless of plan.