Lovable Prompt Library: Briefs, Changes, and Acceptance Checks

Lovable prompts work best when they say precisely what to build, what not to touch, and how to verify the result. Vague instructions produce apps that mostly work; specific ones produce apps you can ship. A tool like fenbs keeps the decisions and tested prompts from earlier iterations so you can start each new session with the full history, not just whatever you remember.

The templates below cover three moments in a typical Lovable project: writing the initial specification, requesting a change to what already exists, and checking whether a feature meets its requirements. Each uses bracketed placeholders for the details that change between projects.

Writing a clear specification

A specification tells Lovable what to build, who will use it, and what success looks like. The more precisely you define the core job, the less Lovable will add features you did not ask for. Start with the minimum you need working before you add anything else. A good specification is a deliberate constraint, not a complete description of everything the app might eventually do.

Build a [type of app: web app / dashboard / form / landing page] that [main job in one sentence].
Users: [description of who will use it].
Required features:
1. [Feature 1]
2. [Feature 2]
3. [Feature 3]
Start with the core layout only. Do not add features that are not listed above.
Visual style: [color scheme, font style, or reference design if you have one; otherwise leave plain].
When the first version is complete, list what was built and what was intentionally left out.

The final instruction, asking Lovable to list what was built and left out, creates a record you can compare against your requirements. It also surfaces assumptions Lovable made that you may want to change in the next iteration. Save that list as a decision note so the next session starts from a known state.

Change request prompts

Change requests are where Lovable projects most often go wrong. A prompt that is too broad can trigger a rebuild of sections you were happy with. The template below limits the change to a single named element and asks Lovable to describe everything it touched.

The current version has [describe the relevant part of the app as it is now].
Change [specific element: a button / a form field / the navigation / the color scheme] to [new behavior or appearance].
Do not change anything outside [name the component or section].
When done, list what changed and what you did not touch.

If you are making several changes, send them as separate prompts rather than combining them in one message. Separate prompts make it easier to identify which change caused a problem and to reverse a specific change without undoing everything else.

When a change request produces an unexpected result, save the failed prompt and the result as a note. Knowing what Lovable did when given an ambiguous instruction prevents you from making the same mistake in a different iteration.

Acceptance check prompts

An acceptance check asks Lovable to review what it built against your stated requirements before you declare a feature done. Running a check after each iteration catches regressions early and gives you a structured record of what was verified.

Look at the current version of [feature or page name].
Check whether it meets each of these requirements:
1. [Requirement 1]
2. [Requirement 2]
3. [Requirement 3]
For each requirement, say whether it passes, fails, or is unclear, with a one-sentence reason.
List any requirement that passes conditionally, meaning it works in some cases but not all.

Save the acceptance check results alongside the version they apply to. When a feature breaks in a later iteration, having the previous passing check tells you exactly what the working version looked like. Record these results in fenbs decisions so they stay with the project, not in a chat that gets archived.

Common mistakes in Lovable prompts

• Combining multiple changes in one prompt. Even if Lovable handles them correctly, you cannot tell which change caused a problem later.
• Describing the solution instead of the requirement. "Add a modal" tells Lovable what to build; "the user needs to confirm before deleting" tells it what to achieve. The second gives Lovable room to pick the right approach.
• Skipping the acceptance check. A feature that looks right in a screenshot may fail an edge case you did not test. Structured checks catch this before users do.
• Not recording what worked. A prompt that produces a good result is worth saving. The next iteration may need the same approach, and searching through old chats is slow.
• Not stating what to preserve. When you ask for a change, say explicitly what you want left alone. Without this instruction, Lovable may optimize for the requested change at the expense of something you already approved.

Keeping decisions between iterations

Each Lovable session starts fresh unless you supply context. Requirements agreed in an earlier session, design choices made last week, features deliberately left out of scope: none of these survive the session unless you record them somewhere persistent and load them into the next conversation.

A record of past decisions also protects you from changing something you already thought through. When you see "we decided not to add search because the dataset is small enough to scroll" in Decisions, you do not have to re-evaluate that choice in every iteration. The reasoning is already there.

For a comparison of Lovable and Claude Code as app-building tools, Lovable vs Claude Code covers the trade-offs. For prompt engineering principles that apply across tools, prompt engineering has the foundations.

How to do this with fenbs

A Lovable project benefits from a persistent record of what was decided, what was tested, and what the next iteration should achieve. Build that record in fenbs from the first session.

1. Create a free account. Add your Lovable project as a project in fenbs with a one-sentence goal and the scope of the first version.
2. Write the core requirements as Decisions and rules. Each requirement should say what the app must do, not how it must look. These become the acceptance criteria for every check.
3. Save your specification, change request template, and acceptance check prompt in Skills and prompts. Name each one so the next session can retrieve the right template without guessing.
4. Connect your AI apps at Integrations. A connected assistant can read your requirements and past results at the start of each session and save what it learned before it closes.