Lovable prompts that work — structure, templates and fixes

The four-part structure

Every reliable prompt answers four questions:

1. What should be true when this is done?
2. Where — which page, component or table?
3. Rules — the constraints that must hold.
4. Don't touch — what must remain exactly as it is.

Example:

On the /pricing page, add a monthly/annual toggle above the plan cards. Annual shows a 20% discount and a "2 months free" badge. Use the existing card component and design tokens. Do not change the plan data, the header or any other page.

That prompt cannot be misread.

Copy-paste templates

New feature

Add [feature] to [page]. It should let a signed-in user [action]. Store the data in [table] with fields [list]. Only the owner can read or edit their own rows. Reuse the existing components and styling. Do not change [protected areas].

Styling change

On [page], change [element] to [exact value: size, colour token, spacing]. Keep it responsive — [behaviour] on mobile, [behaviour] on desktop. Do not change any other page or the design tokens.

Bug fix

[Describe what you did] and [what happened instead of what you expected]. The exact error is: [paste error verbatim]. Diagnose the cause before changing anything, tell me the cause, then apply the smallest fix.

Database

Create a [table] table with [fields and types]. Enable row-level security. A signed-in user can insert their own rows and read, update and delete only their own. Admins can read all rows. Add sensible defaults so inserts from the app do not fail.

Refactor without visual change

Refactor [file/component] for readability. The rendered output and behaviour must be identical — no visual or functional change. Explain what you changed.

Content page

Create a /[slug] page titled "[title]". Sections: [list]. Match the existing site layout and typography, add proper page metadata for search engines, and link it from the footer.

Phrases that save you money

• "Do not change anything else."
• "Show me the plan before making changes."
• "Make the smallest possible change."
• "Reuse the existing [component] instead of creating a new one."
• "Keep the current design system — no new colours or fonts."
• "Explain what caused this before fixing it."

Phrases that cost you money

• "Make it better." Better how? You will pay for the guess and the correction.
• "Fix everything." Unbounded scope, unbounded diff.
• "Add a login system, payments and an admin panel." Three features, one failure surface.
• "It's broken." No symptom, no error text, no page name.

Prompting for design

Design prompts work when they are concrete. Instead of "modern and clean", say:

Use a warm off-white background, one accent colour for primary actions, generous section spacing around 96px on desktop, a serif display font for headings and a sans-serif for body text. Cards get subtle borders, not heavy shadows.

Reference something real where you can: "layout like a documentation site — fixed sidebar, wide reading column."

When it goes wrong

1. Stop re-prompting. Two identical failures mean the third fails too.
2. Paste the exact error text.
3. Ask for a diagnosis first, a fix second.
4. If the project is in a worse state than ten minutes ago, revert and retry with a tighter prompt.

Build order that makes prompts easier

Data → one screen → next screen → auth → polish. Each stage gives the next prompt a stable foundation, so requests stay small and specific — which is the whole game.