How to Write a Good Lovable Prompt
The structure of a build prompt that gets a usable result first time: context, scope, behaviour, constraints and acceptance criteria.
Published 24 Aug 2026 · Tested with Lovable as of 24 Aug 2026
Overview
A good prompt reads like a short brief to a competent contractor. It states the goal, the scope, the behaviour and what "done" looks like.
Beginner explanation: Vague prompts produce generic results. Specific prompts produce specific results — including specific mistakes you can then correct.
Technical explanation: Include acceptance criteria. Listing what must be true when the change is finished gives the build something concrete to satisfy and gives you something concrete to test.
Steps
- Context — what the project is and who uses it.
- Goal — the one outcome you want from this prompt.
- Scope — what to build, and explicitly what not to touch.
- Behaviour — what happens on click, on error, on empty state.
- Acceptance criteria — a short checklist of what must be true afterwards.
:::tip End long prompts with: "Do not change anything outside the scope described above." :::
What to check afterwards
- Everything in your acceptance list is true
- Nothing unrelated changed
- Empty and error states exist, not just the happy path
Common problems
- Multiple unrelated goals in one prompt. They interfere.
- No error or empty states requested. You will get only the happy path.
- No scope boundary. Unrelated files get rewritten.
Where people get stuck
If you have followed the steps and the result still is not right, the fastest path is usually to describe the exact behaviour you expected, the behaviour you got, and any error text, then ask for a fix in one focused follow-up prompt. If that loop is not converging, hand it over.
