Lovable Prompts: 8 Fill-in-the-Blank Templates You Can Copy Today

The Lovable prompts that work best name one job, one place, and what to leave alone. Below are 8 templates, one for each moment of a build, from the very first prompt to a last read of your page through a customer's eyes. Fill in the brackets, paste, and check the result before you send the next one.

This guide is a set of templates organized by the job in front of you. The habits behind them (one change at a time, saving versions, keeping a log) live in our guide to vibe coding best practices, and the repair steps for when something breaks live in fixing an AI-built app without starting over. The templates also work as vibe coding prompts in other builders, though the Chat mode and knowledge tips are Lovable features.

What makes a Lovable prompt worth copying?

A prompt worth copying is one where you only change the brackets. The shape behind these comes from Lovable's own prompting guide, which breaks a good change prompt into 3 parts: what to build, where it goes, and what must stay untouched. The same guide suggests inviting the tool to ask you questions before it builds, a short line that saves a lot of guessing.

Say there's a community theater (we invented it) that wants a page for reserving seats at its spring play. We'll use it to fill in a few templates.

How do you write the first build prompt?

This prompt sets the direction for everything after it, so it's worth a few extra minutes. Lovable's guide suggests answering 4 questions first: what this is, who it's for, why they'll use it, and the one key action.

Build a [page or app type] for [who it's for]. The one thing a visitor should do is [main action]. They come here because [the reason they care]. Sections, in order: [section 1], [section 2], [section 3]. The feel: [2 or 3 style words]. Use this real text, not placeholders: headline "[your headline]", button "[your button words]". Before you build, ask me whatever you need to know.

Why it works: it hands over the 4 answers Lovable asks for, plus real words, so the first draft has something specific to respond to.

For the theater, the 2 lines that matter most might read: "The one thing a visitor should do is reserve seats for one performance" and "The feel: warm, friendly, a little old-fashioned playbill." The first keeps the page about tickets. The second keeps it from looking like every other booking page (and gives the playbill fans in the cast something to love).

How do you ask for one new feature?

Once the first version works, this lets you add to it without losing what you have: one feature, in steps you can check, much like Lovable's product-building guide suggests.

Add [feature] to the [page name] page. Who uses it: [which kind of user]. [Other users] should not see it. Go one step at a time, and stop after each so I can check it: 1) the screen with sample data, 2) saving real data, 3) what happens when it's empty, loading, or fails. Don't change [the parts that already work].

Why it works: each step is a checkpoint, and naming who sees the feature keeps it off screens meant for someone else. For the theater, that might be a sold-out label on full performances.

How do you change one thing without breaking the rest?

This is the template I'd keep closest, because small requests are the ones that surprise you. A tweak to one button can ripple into a page that already worked, which is why Lovable's docs suggest naming the boundary even when it feels obvious.

On the [page name] page, change [the exact element] so that [new behavior or look]. Only change [that element]. Keep [styling, layout, or flow you like] exactly as it is. Don't touch [page or feature that works].

Why it works: the "only" and "don't touch" lines put a fence around the change, and a fence is much easier than a cleanup.

If you can point at the thing, Lovable also has a preview toolbar for selecting the exact element and describing the change right there.

How do you get Lovable to explain what it changed?

You asked for a new button and the whole page feels slightly different. Time to ask for the receipts, ideally in Chat mode, which Lovable describes as a place to ask about your app without changing any code.

In plain English, explain what you changed in your last response. List each page or part of the app you touched, and why. Tell me anything that might behave differently now, and what I should test. Don't change any code.

Why it works: you get a list to check against what you asked for, and the last line keeps a question from becoming an edit.

How do you describe a bug so it gets fixed?

You pressed the button and nothing happened, again. Frustrating, and completely normal. A calm, specific prompt covers what Lovable's debugging page asks for: what's broken, where, what you expected, and what happened instead.

On the [page name] page, when I [exact action], [what happens]. I expected [what should happen]. This worked [before my last change / yesterday / never]. Here is the exact error message: [paste it]. Find the root cause and explain it before you change any code.

Why it works: specific evidence gives the fix something to aim at, and asking for the cause first stops a pile of guesses. Add a screenshot for layout problems. If the bug keeps coming back, our guide on fixing errors without starting over has the full method.

How do you make it work on a phone?

I'd assume a lot of people will open your link on a phone, so this one earns a regular spot. Lovable's preview has a device toggle that switches to Mobile view, and the template below gives the phone its own instructions.

Make the [page name] page work well on a phone. On mobile: [what should change, like one column or a shorter menu]. The [main button] must be visible without scrolling on a small screen. Make tap targets comfortable for a thumb. Keep the desktop layout exactly as it is.

Why it works: it names what a phone visitor must be able to do, and protects the desktop version you like.

For the theater, the filled-in middle lines might read: "On mobile: stack the performance dates in one column, and put the seat count and the Reserve my seats button together under the date picker." Then switch to Mobile view and try to reserve a seat with your thumb. Under Mobile and Access, our audit asks the same question: can a visitor see the main action on a real phone without scrolling or guessing?

How do you swap generic copy for your own words?

In my view, AI-written copy tends to sound like everyone else's, and that's one of the quickest ways a page reads as generated. This keeps your facts in and the filler out.

Rewrite the text on the [page name] page in my words. Here is what we actually do, in my own voice: [2 or 3 sentences, written by you]. Who it's for: [specific people]. Keep these exact phrases: [phrases you want kept]. Cut these phrases: [generic ones, like a vague "Get Started"]. Don't change the layout, only the words.

Why it works: your own sentences are the most real content there is. Our guides on website copy and design polish go deeper.

How do you ask for a read through a customer's eyes?

This one gives you a first-time visitor before you have any, with the builder playing the part. A second opinion on a design, a flow, or copy is on Lovable's own list of what Chat mode is for.

Read the [page name] page as a first-time visitor who knows nothing about [your business]. In one sentence, what do you think this page offers? What would you click first, and what would make you hesitate? Is anything confusing, missing, or hard to trust? Rank the problems from biggest to smallest. Don't change any code.

Why it works: it turns "does this look fine?" into questions about clarity, trust, and the main action.

One caution: the tool built the page, so it's grading its own homework, and I'd expect it to be a generous grader. For a read from outside the builder, we made Is My App Slop. Every fix in the report is ranked, and each comes with a prompt you can paste straight into your builder. Our sample report shows what that looks like.

Where should your favorite prompts live?

Somewhere you'll find them again. Lovable's knowledge feature holds instructions the tool considers on every edit, which suits your style words and anything it keeps getting wrong. The templates can sit in your own notes, next to your build log. For ready-made Lovable prompt examples for features like sign-in or payments, there's a prompt library in Lovable's docs.

One more set comes later. Every Is My App Slop report includes a free 35-prompt guide for the marketing and sales moments after you ship, so it picks up where these build prompts stop.

Sources, all read 13 October 2026: Lovable's Prompting best practices page, Debug and improve your app page, How to build a real product with Lovable page, Prompt library, Chat mode page, and Knowledge page (none shows a page date).