Lovable prompts for specs, UI, auth, database and fixes

The Lovable prompts that work best describe one change at a time, use real content instead of placeholders, and say what must stay untouched. Below are 14 original prompts that follow a real build in order: spec, project knowledge, UI, data and auth, security, and fixing what breaks.

How to use these prompts

Copy a prompt into the Lovable project chat and replace the blanks in double braces, or keep the default after the colon: {{audience:freelance designers}} means freelance designers unless you change it.

Lovable's project chat has three modes, described in the Plan mode docs:

Each prompt below says which mode suits it. Two habits from Lovable's prompting best practices matter more than wording: build one component or feature at a time and check it in the preview, and name the boundary ("only change the settings page") so a small request doesn't ripple into parts that already work.

Plan the product

1. Turn an idea into a short spec (Chat mode)

Start here before any building. The questions at the end catch the decisions you haven't made yet.

I want to build {{idea:a booking app for independent yoga teachers}}.

Who it's for: {{audience:teachers with 5 to 50 regular students}}
The one thing users must be able to do:
{{key_action:book and pay for a class in under a minute}}

Don't build anything yet. Write a one-page spec:
1. The problem in two sentences.
2. User types and what each can do.
3. The screens, in the order a new user sees them.
4. The data the app stores.
5. What's in version one and what's explicitly left out.

Then ask me up to five questions about anything that would change the
design.

2. Draft your project knowledge

Project knowledge is included on every message, so Lovable stops forgetting your rules. Ask Lovable to write a first draft from the spec, then paste it into Project settings > Knowledge.

Using the spec we agreed on, draft project knowledge text I can save.
Keep it under 2,000 characters and use short lines under these headings:

- What this app is and who uses it
- Design direction: {{style:calm, minimal, lots of white space}}, with
  one accent color, {{accent:#2f6f5e}}
- Data rules: who can see and change which records
- Copy rules: {{tone:plain, friendly, no exclamation marks}}
- Never do:
  {{never:add features I didn't ask for, change the auth flow without asking, use placeholder text}}

Only output the knowledge text.

3. First build: the core flow only (Build mode)

Ask for the smallest version that does the key action end to end. Everything else comes after.

Build version one of the app from our spec, but only the core flow:
{{core_flow:a student opens a teacher's page, picks a class, and books it}}.

Include only the screens that flow needs. Use real copy that fits the
product, not lorem ipsum. Use sample data for now; we'll add a real
database next. When you're done, list what you built and what you left
out on purpose.

Build the UI

4. One component with real content

Lovable's docs recommend prompting by component, not by page. Write the actual words you want, so the layout fits the real copy.

Add a {{component:pricing section}} below the {{anchor:features section}} on
the home page.

Content:
{{content:Three plans. Starter: free, up to 10 bookings a month. Studio: $19/month, unlimited bookings and payments. Team: $49/month, up to 5 teachers.}}

Layout:
{{layout:three cards in a row on desktop, stacked on mobile, the middle card highlighted}}.
Each card has a plan name, price, three short benefit lines and one button.

Only change the home page. Keep the existing header, fonts and colors.

5. Set the visual direction once

Use this early, then save the result to knowledge so new screens match.

Restyle the app with this direction:
{{direction:warm and calm, soft neutral background, one green accent, rounded corners, generous spacing, a friendly serif for headings and a clean sans-serif for body text}}.

Apply it to the existing screens without changing layout, copy or
behavior. Then give me a short style summary (colors with hex values,
fonts, corner radius, spacing scale) that I can paste into project
knowledge.

6. Empty, loading and error states

Generated apps often show only the happy path. This pass fills in what users see when data is missing or slow.

Go through {{scope:every page that shows data from the database}} and
add the missing states:

- Loading: a skeleton that matches the final layout.
- Empty: a short message that says what to do next, with a button
  where it helps (for example "Add your first class").
- Error: a plain message and a retry button. No technical details
  shown to users.

Don't change the layout of the loaded state. List each page and the
states you added.

7. Point at an element and change only that

Select the element with the preview toolbar first, so Lovable knows exactly what you mean, then send a narrow instruction.

For the selected element:
{{change:make it the main call to action: solid accent background, white text, slightly larger, and change the label to "Book a class"}}.

Keep its position, the surrounding layout and every other button on
the page exactly as they are.

Add data and auth

8. Design the data model first (Plan mode)

Data structure is the hardest thing to change later, so plan it before building. Lovable's built-in backend includes a managed database, authentication, storage and edge functions.

Plan the database for this app before building anything.

Things it stores: {{entities:teachers, students, classes, bookings, payments}}
Who can see what:
{{access:teachers see their own classes and bookings; students see their own bookings; nobody sees other people's payment details}}

Propose tables, columns, relationships and which user owns each row.
Explain the access rules for each table in plain language. Point out
anything that will be hard to change later, and ask me about anything
you're unsure of.

9. Login with roles

When you ask for login, Lovable's authentication docs say it generates the signup and login pages and protects user data with row level security. Name the sign-in methods and roles you want, or it picks defaults.

Add login. Sign-in methods: {{methods:email and password, and Google}}.

Roles:
{{roles:teacher and student. New users choose a role at signup. Only teachers can create classes.}}

Require login for {{protected:the dashboard and booking pages}}. The
public teacher pages stay open. After login, send teachers to
{{teacher_home:/dashboard}} and students to {{student_home:/my-bookings}}.

Make sure each user can only read and change their own data, and tell
me which access rules you added for each table.

10. Check who can see what (Plan mode)

Lovable's security docs name misconfigured row level security as a common cause of data leaks. Run this before inviting real users, and run Lovable's built-in security scans too.

Review the access rules on every table without changing anything.

For each table, tell me in plain language:
- Who can read, create, update and delete rows.
- Whether a logged-out visitor can read anything.
- Whether one user could read or change another user's data.

Then test these cases by reasoning through the rules:
{{cases:a student tries to see another student's bookings; a teacher tries to edit another teacher's class; a logged-out visitor opens the bookings list}}.

List any gap as: table, problem, fix. Wait for my approval before
changing anything.

11. Connect an outside API safely

For payments, email or any third-party service. The key goes into secrets, never into the code.

Connect {{service:Resend}} so the app can
{{job:email a student when their booking is confirmed}}.

- Store the API key as a secret, never in frontend code. Ask me for it
  when you need it.
- Call the service from a backend function, not from the browser.
- If the call fails, the booking still succeeds and the failure is
  logged.

Before building, tell me what you'll add and where. After building,
tell me how to test it.

Fix what breaks

12. A bug report Lovable can act on

Vague bug reports get vague fixes. Say what, where, expected and actual, and attach a screenshot or the console error if you have one.

Bug on {{page:the bookings page}}.

What I did: {{steps}}
What I expected: {{expected}}
What happened: {{actual}}
Error message (if any): {{error:none shown}}
It worked before: {{worked_before:yes, until we added payments}}

Find the cause before changing code. Explain it in two sentences, then
make the smallest fix. Don't change anything unrelated to this bug.

13. Stop the fix loop (Plan mode)

If two fixes in a row didn't stick, stop asking for more. Lovable's debugging guide suggests switching to Plan mode to find the root cause.

We've tried to fix {{problem:the duplicate bookings bug}} twice and it
keeps coming back. Don't change any code yet.

1. List what we've already tried and why each attempt didn't work.
2. Trace the flow from {{start:the "Book" button}} to
   {{end:the saved booking}} and find where it goes wrong.
3. Give the root cause, with the evidence.
4. Propose one fix that removes the cause, not the symptom, and say
   what it could affect elsewhere.

14. Pre-launch check (Plan mode)

Run this once before you share the app or connect a custom domain.

I'm about to launch. Review the whole app without changing anything and
give me a checklist, grouped by severity:

- Security: data access rules, secrets in frontend code, admin pages
  reachable by normal users.
- Broken flows: test step by step:
  {{flows:signup, login, booking, cancel booking, password reset}}.
- Mobile: any page that breaks below 400px wide.
- Content: leftover placeholder text, sample data, broken links.
- Basics: page titles, favicon, a 404 page.

For each item: page, problem, suggested fix.

What else helps in Lovable?

Bookmark working versions. Lovable saves every change to version history, and a bookmarked known-good state makes bold experiments cheap: if a change goes wrong, revert to it (this restores code, not database data) and try again with a tighter prompt instead of stacking fixes.

Keep project knowledge current. When you settle a design direction or a data rule, add it to knowledge so you don't have to repeat it. Lovable also keeps its own prompt library with ready-made prompts for common features.

For prompts that work in any agent, see the vibe coding prompts and the debugging prompts. If you build UI in Vercel's builder or work in an editor, the v0 prompts and Cursor prompts pages follow the same approach.

Save the prompts you reuse

Once a prompt works, keep it. Kipt saves your prompts as Markdown in a private GitHub repo you own, with {{blanks}} you fill in each time, tags, and Cmd+K search, so your spec, bug report and pre-launch prompts are ready for the next project.