Four prompts ago the app worked. Each one since did the thing you asked for and moved something else with it: the sign-in button changed colour, the filter on the bookings list stopped filtering, a page nobody mentioned now scrolls wrong. Searching for Lovable prompts in that state returns prompt libraries, and every one of them is written for a project that does not exist yet.
So this page skips the library. It covers how to word a change to an app that already has users, what Lovable documents feeding its own agent on every message, and the three prompt shapes that reliably make things worse. If you came for prompts that build something new from an empty project, the vendor’s own best-practices page and the prompt shops on the same search results page do that job better than anything below.
A Lovable prompt that changes one thing needs three parts: what to change, where it lives, and what must stay untouched. Lovable’s own guidance says the same. Without that third part, a small request reaches into working code, because nothing told the agent where to stop.
Everything below was read off Lovable’s own prompting, prompt-library, debugging, knowledge and changelog documentation on 25 August 2026, plus Replit’s prompting tutorial for the one place the two vendors disagree. No prompt on this page was sent to a builder for this article, and no leaked copy of any agent’s instructions was opened or reproduced.
Why does one Lovable prompt change things you did not ask about?
A prompt states the outcome you want and leaves the edits to the agent, which decides how far to reach. Anything you did not fence sits inside that reach. Lovable’s own prompting page names the effect: a small request can ripple into parts of the app that already work.
That sentence is the vendor’s own. Lovable’s prompting best-practices page puts it plainly, inside a technique it calls “Say what to change and what to leave alone”: “Lovable moves fast, and without boundaries a small request can ripple into parts of the app that already work.” Then it says what to do about it: “Naming the guardrails keeps the change contained.”
The mechanism behind the ripple is dull. You typed a goal. The agent has to turn that goal into a list of files to edit, and it has no way to know which of your working screens you would rather it left alone unless the message says so. A shared button component looks like fair game when you asked for a nicer button. The routing file looks like fair game when you asked for a new page. Nothing in the request marked either one as off limits, so both are inside the answer.
The state people describe in public is every prompt turning the whole app over, one request at a time, and the fix they reach for is a longer prompt. Length is the wrong lever. A four-hundred-word request with no boundary in it is still unbounded. One extra sentence naming what must not move does more than four extra paragraphs describing what you want.
There is a second situation that looks identical from the outside and needs a different answer. When every fix opens two new breaks and the pattern repeats for a week, the repeat itself is the problem rather than any one prompt. And when the damage happened in a single step, a single AI edit broke a feature that had been working is the sequence for finding what moved and getting back.
The three parts of a Lovable change prompt
Lovable defines the shape in one sentence on its prompting page: “A good change prompt has three parts: what to build, where it goes, and what must stay untouched.” Most people send the first part and stop.
Here is the same shape as something you can paste and fill. Lovable documents the first three lines. The fourth comes from the way its own prompt library writes a bug prompt, and the section on putting the check inside the request explains why it belongs in every change you send.
Change: add a status filter to the bookings list.
Where: the bookings page only.
Do not touch: sign-in, the payment page, the customer table, or the styling anywhere else.
Done when: I can pick a status, the list shows only bookings with that status, and every other page looks and behaves exactly as it does now.The third line is the one that feels rude to write and is worth writing anyway. Lovable’s page is direct about this: “Spell out the boundary even when it feels obvious: ‘only change the orders page,’ ‘keep the existing styling,’ ‘do not touch login.’” Its own worked example under that technique ends the same way, with “Only change the orders page. Keep the table’s existing styling and leave the rest of the app unchanged.”
Four ordinary requests, before and after.
| The prompt people send | The same request, fenced | What the fence stops |
|---|---|---|
| Add a filter to the bookings list | Add a status filter to the bookings list. Only change the bookings page. Keep the existing table styling and leave the rest of the app as it is. | A filter added to every list in the app, and a table restyled while it was open |
| The signup form needs a phone number | Add an optional phone number field to the signup form, after email. Do not change what happens on submit, do not change sign-in, and do not add a new library for validation. | A field that arrives required, a changed submit handler, and a package added to the project nobody asked for |
| Make the pricing page match our brand colour | Change the button and heading colours on the pricing page to our brand blue. Only the pricing page. Do not change the shared button component or any other page. | An edit to the shared component, which repaints every button on the site |
| We need an about page | Add a new page at /about with a heading, three paragraphs and a photo, and one link to it in the footer. Do not change the header, the home page, or the routing for any page that already exists. | A rewritten navigation, and a routing change that breaks a link customers already bookmarked |
Read the middle column as one message each. Every one of them is shorter than the paragraph most people write when they are frustrated, and every one of them names a place.
Two smaller habits from the same page are worth stealing. When the thing you want changed is on screen in front of you, Lovable documents pointing at it with the preview toolbar instead of describing it in words, which it frames as an adjustment rather than a replacement. And when a request is big enough that you are guessing at half of it, you can end the message with the line the docs give verbatim: “Ask me any questions you need in order to fully understand what I want from this feature and how I envision it.” Plan mode, Lovable notes, works especially well for that.
Marking the working version before you send a risky change is one line of habit here, and where the History panel keeps those versions, why the Revert control sometimes will not move, and what a restore does to your database are somebody else’s subject.
Three Lovable prompts that make it worse
Three shapes come up again and again, each one named or contradicted by a vendor’s own documentation, and each one has a short fixed version.
“Nothing works, fix it!” is Lovable’s own example of what to avoid. Its debugging guide lists it under “Avoid generic and broad prompts”, and the reason it fails is that it names no place. The agent has to pick somewhere to start, so it picks, and now you have a change you did not choose on top of the bug you already had. The fixed version pins the symptom to a place and a moment: “The screen goes blank when I open the bookings page after signing in as a customer account. It loaded yesterday. Nothing else changed that I know of.”
“Make it better.” Quality words give the agent nothing to act on, because better is a matter of opinion and the agent has to guess whose. Lovable’s own wording, in the technique it gives for editing one named element, is to swap them for direction: “Be precise about what changes and what stays the same, using direction like ‘replace,’ ‘update,’ or ‘adjust’ rather than ‘make this better.’” Replace the heading font. Update the empty state text. Adjust the card padding to 24px. Each one is checkable when it comes back.
The whole-page or whole-app prompt. “Redesign the whole site to look more modern” is an unbounded number of edits under one request, and no amount of careful wording localises it afterwards. Lovable’s page states the trade in six words: “A full-page prompt gets you noise. A section-based prompt gets you signal.” Break it into sections, send one, look at it, then send the next. If the app is already messy enough that you are tempted to send the whole thing in one go, asking for one safe change at a time across a whole messy app is a job with its own order.
Now the part where two vendors appear to disagree. Replit’s prompting tutorial gives the opposite instruction about negatives. Under a heading called “Use positive language”, Replit’s tutorial says: “State what you want, not what to avoid.” Its example of the bad version is “Don’t make the user profile page confusing.” Lovable, on the same subject, tells you to write “do not touch login” and means it.
Both are right, about different negatives. A negative that names a quality is a wish, and it gives the agent nothing to act on: confusing, ugly, slow and messy are all judgements the model has to invent a definition for. A negative that names a place is a fence, and a fence is a fact the agent can obey: the login page, the customer table, the shared button component. Keep the second kind and drop the first. That distinction is the whole of the disagreement, and it holds on Replit prompts as squarely as it does on Lovable ones.
What is the Lovable system prompt, and which part of it do you write?
Lovable does not publish the instructions its agent starts from. What it does publish is the list of five things it reads on every message, and two of those five are fields you write yourself: project knowledge and workspace knowledge. Those are the part of the context you control.
Copies of an agent prompt circulate on GitHub and Reddit. Lovable did not publish them, nothing here reproduces them, and nothing here treats them as accurate. Across Lovable’s prompting, prompt-library, debugging, knowledge and changelog pages read on 25 August 2026, its published documentation does not print the instructions its agent starts from. That is the honest answer to the literal question, and it takes one sentence.
The useful half of the question has a documented answer that almost nobody quotes. Lovable’s knowledge documentation states, in its FAQ, exactly what goes into the model on each message: “When you send a message, Lovable reads your project knowledge, workspace knowledge, and project code to understand how your project works before generating edits. It also looks at any integration knowledge from connected services, including the connector knowledge files of custom connectors, and instruction files in your project’s Git repository such as AGENTS.md or CLAUDE.md.”
Five channels, each with its own job and its own documented limit.
| Channel | What it is for | Always in context | Documented limit or caveat |
|---|---|---|---|
| Project knowledge | Context for one project: what the app does, who uses it, key database tables, architecture decisions, domain words | Yes | Up to 10,000 characters. When the same instruction appears in both knowledge fields, Lovable “will generally prioritize project knowledge, since it is more specific to the current project” |
| Workspace knowledge | Rules shared across every project in the workspace: coding standards, preferred libraries, naming, brand voice, and “Things Lovable should avoid doing” | Yes | Up to 10,000 characters. One per workspace, managed only by workspace owners and admins, at Settings then Knowledge or Project settings then Knowledge |
| Project code | The code already in the project, read so the agent understands how it works before it edits anything | Yes | You do not write this one. It is the reason a vague request still produces plausible edits |
| Integration knowledge from connected services | What Lovable knows about the services you connected, including the connector knowledge files of custom connectors | Read on each message | Varies with what is connected. Lovable’s docs describe it as part of the context, not as something you edit as text |
| Instruction files in the project’s Git repository | Repository-level instructions in files such as AGENTS.md or CLAUDE.md | Root-level AGENTS.md, yes | ”root-level AGENTS.md files are always read by the Lovable agent regardless of session length” |
Two rows of that table are the ones worth acting on today.
The first is a caveat Lovable writes about itself, which is unusual enough to quote in full: “Workspace knowledge is always included together with project knowledge alongside project code and other context sources. However, in very long conversations with a lot of context, instructions may not always be followed consistently.” So the rule you wrote on Monday is not a guarantee on Thursday afternoon in the same chat thread. If a standing instruction stops holding and the chat is long, the chat length is a candidate cause before the wording is.
The second is the one channel the same page documents as immune to that: “For technical users managing instruction files directly in their repositories, root-level AGENTS.md files are always read by the Lovable agent regardless of session length.” If your Lovable project is connected to a repository, that file is the sturdiest place to put the two or three rules you never want dropped. Being read is not the same as being followed, so the rules still get checked the same way as everything else: one change at a time, in the browser.
What belongs in a repository instruction file, how long it should be and which coding tools read it are covered where the format itself is covered: what an AGENTS.md file is and which tools read it.
One dating note, because the knowledge fields feel new and readers reasonably ask how new. Lovable’s changelog dates workspace knowledge to 16 March 2026 and workspace skills to 18 May 2026. As of 25 August 2026 it carries no entry announcing project knowledge as a feature of its own, so the documentation page is the only public record of how that half works. Knowledge and skills are also not the same mechanism: knowledge, in Lovable’s words, “is always included in context”, while a skill loads only when a request matches that skill’s description.
Put the check inside the request
The habit that costs nothing is saying how you will know it worked, in the same message that asks for the change. Lovable’s own prompt library does exactly this in the bug prompt it publishes: “The page crashes when I click my profile. Reproduce it in the browser, fix it, and then verify that your fix worked.”
Read the shape of that. The request and the proof are one message, so the agent has no version of “done” available that honestly skips the check. It can still report a check it did not run, which is why the next paragraph matters. Without the last clause, done means the edit was written. With it, done means the edit was written and the thing was tried.
The failure mode worth guarding against here is a confident report of success. One person posting about a Replit app they had already built and uploaded to the Play Store put it like this: “aab build already and uploaded in playstore Given prompt for adding push notification, agent said everything correct. But, notification is not triggering”. Nobody in that exchange had asked the agent to prove a notification arrives, so nothing in its answer was wrong by its own standard. The check was missing from the request.
Lovable’s own suggested workspace knowledge includes the same idea as a standing rule, phrased as verifying new functionality in the browser before marking it complete. That is worth having in both places: once as a standing line, and once in the message, because of the long-conversation caveat above.
Two smaller rules from Lovable’s prompt library belong in the same habit. “Run one prompt at a time. Review the result, then move to the next feature”, which is the same instruction its best-practices page gives as making one meaningful change at a time. And “Save decisions that should persist, such as your design direction and product context, to your project knowledge, so every later prompt builds on them automatically”, which is the bridge to the next section.
Once the change comes back and the screen still does the wrong thing, the question stops being how you asked and becomes what the tool is claiming, and the record that settles a repair that has already failed several times is its own page.
Ten lines worth putting in your project knowledge
Project knowledge is a plain text field, not code, and Lovable’s guidance on writing it is short: be specific, and “Imagine explaining the project to a new developer joining the team.” Its example of a good line is “Always enable TypeScript strict mode. Never use any.” Its list of what workspace knowledge is best for ends with the category most people never fill in: “Things Lovable should avoid doing.”
The ten lines below are derived from that documented guidance and aimed at the things that actually break on an app with users. They are not copied from a vendor list, and Lovable publishes nothing like them. Paste what fits, delete what does not, and keep it under the documented 10,000 characters.
- 01 One change per message. If I ask for two things, do the first and ask me about the second.
- 02 Name the screen or feature you changed and state that everything else stays as it is.
- 03 Do not change sign-in, payments, or the customer table unless the message says so by name.
- 04 Do not add a new package or library without telling me which one and why, and wait for my answer.
- 05 Keep the existing styling and the shared components unless the message asks for a style change.
- 06 At the end of every change, list what you changed and where, one line per file or screen.
- 07 Verify the change in the browser before you report it as done, and say what you checked.
- 08 Ask before deleting anything: a file, a table, a column, a route, or a page.
- 09 If the request is ambiguous, ask one clarifying question first instead of guessing.
- 10 This app is a booking tool used by staff at three locations, and real customers pay through it.
The last line looks like the softest and does the most work, because it is the only one that tells the agent what the stakes are. Replace the description with your own in one sentence.
Two boundaries on this list. Prompts written for the boundaries that protect customer data are a separate set with their own reasoning, one per boundary, and this is not that list. And the same idea in Claude Code, written down as a rules file covers the rules-file version of this at length, including why a file that grows past a certain size gets followed less carefully as it grows.
One practical note on timing. Lovable documents that knowledge edits take effect immediately: “If you update workspace knowledge during an active conversation, Lovable will use the updated instructions on follow-up messages.” So you can add a line the moment something goes wrong, and the next message gets it.
What the Lovable prompting guides leave out
The prompt libraries are good at the job they were written for, and that job is mostly not yours today. Lovable’s own library does carry a repair prompt and a review-the-next-feature prompt, quoted above, but read a Lovable prompt guide from any of the other pages currently ranking and you will find prompts organised by the feature you want to build, a blog backend, a billing system, a marketplace, with little about protecting what is already running.
The most-cited guide is old. lovable.dev/blog/2025-01-16-lovable-prompting-handbook, the Lovable Prompting Bible, is dated 16 January 2025 and shows no update notice on the page today. That link is left unlinked here on purpose, because the page it sits on sells the product. Nineteen months is a long time here: it predates workspace knowledge, skills, and the preview toolbar as the documentation describes them now, all of which the section above is built on.
The paid generators sell the same shape. lovableprompts.app gives two prompts free, then charges $4.99 a month for twenty prompts, or $24.99 once for a hundred, and it produces opening prompts for Lovable, Bolt, Cursor, Replit and v0. lovable-prompts.com is a prompt shop on the same search results page. rapidevelopers.com publishes a paste-ready prompt kit collection organised by feature. Read the three of them for what they are, which is a good way to start a project. None of them covers keeping the agent off working features, what Lovable reads on every message, or the prompt shapes that make an app worse. Prices checked 25 August 2026.
The video side of the search has the same gap. A Lovable AI tutorial teaches you the first prompt beautifully and stops long before the fiftieth, which is the one that costs you a working feature.
When more prompting is the wrong next move
Three honest signals that better wording is not what is missing.
The first is repetition. The same request has come back wrong several times, each attempt slightly different, and none of them landed. How many tries the same failure gets before a person opens the code is a number this blog publishes, and it is not on this page.
The second is spread. The change touches the screen, the database and the payment together, which means three places have to move in step and any one of them being half-done leaves you worse off than before you started. A prompt that touches four screens is a bigger change than a prompt that touches one, and what that difference costs in credits is priced elsewhere.
The third is that people are using it. Once real customers are on the app, an experiment costs more than the credits it burns, and the calculation changes before the prompt does.
When the request is a repair rather than a change, Lovable publishes its own order of attempts and its own count of free ones, and that ladder is written up where it belongs.
Common questions about prompting Lovable
How do I stop Lovable from changing other parts of my app?
Name the boundary in the same message as the change. Lovable’s own guidance is to spell it out even when it feels obvious, with examples like “only change the orders page,” “keep the existing styling,” “do not touch login.” Add the two or three rules you never want broken to your project knowledge as well, so they are in context on every message instead of only the one you remembered to write them in.
What is the Lovable system prompt?
The instructions Lovable’s agent starts from are not published by Lovable. Copies circulate on GitHub and Reddit, this page does not reproduce them, and none of them can be checked against anything the vendor has published. The documented and checkable part of the question is which context sources Lovable reads on every message, which is the five-row table above: project knowledge, workspace knowledge, project code, integration knowledge from connected services, and instruction files in your repository.
Can I give Lovable permanent instructions?
Yes, in two text fields. Project knowledge holds context for one project and workspace knowledge holds rules shared across every project in a workspace. Both are documented as always included in context, both support up to 10,000 characters, and a change to either takes effect on the next message in an active conversation. Workspace knowledge is managed by workspace owners and admins at Settings then Knowledge, or at Project settings then Knowledge.
Does Lovable read a CLAUDE.md or AGENTS.md file?
Yes, if your project is synced to a Git repository. Lovable’s knowledge FAQ says instruction files such as AGENTS.md or CLAUDE.md can also provide guidance to the agent, and adds that “root-level AGENTS.md files are always read by the Lovable agent regardless of session length”. That last clause is the reason to use one: it is the only instruction channel Lovable documents as unaffected by how long the conversation has run. Which file wins when a repository has both is a question with its own answer, and the format itself is covered on the AGENTS.md page linked above.
Why does Lovable stop following my instructions in a long chat?
Because the vendor documents that it can. Lovable’s knowledge page says workspace knowledge is always included alongside project knowledge and project code, then adds: “However, in very long conversations with a lot of context, instructions may not always be followed consistently.” When a standing rule stops holding late in a long thread, start a fresh conversation before you rewrite the rule, and move anything critical to a root-level AGENTS.md if the project is connected to a repository.
How many changes should one prompt contain?
One. Lovable says it twice in its own documentation, as “Make one meaningful change at a time” on the best-practices page and as “Run one prompt at a time. Review the result, then move to the next feature” in the prompt library. The practical reason is that a message containing three changes gives you one result you cannot take apart: if two landed and one broke something, you cannot keep the good two without unpicking the third by hand.
Are the paid Lovable prompt packs worth it?
For starting a new project, they save you writing the first prompt, and that is a real if small saving. For an app that already has users, they cover the wrong problem: none of the packs on the current search results page addresses boundaries, standing instructions, or verification. The generators charge in the range of a few dollars a month, so the money is not the question. The question is whether an opening prompt is what you are short of, and after the fourth broken feature it usually is not.
What is the best prompt for fixing a bug in Lovable?
The one that ties a symptom to a place and ends with a check. Name the screen, say what you saw, say what you expected instead, and ask for the fix to be tried in the browser before it is called done. Lovable’s library shows the shape: “The page crashes when I click my profile. Reproduce it in the browser, fix it, and then verify that your fix worked.” One caveat, though: a repair that has already failed several times is not a wording problem, and the record that settles it is a different job from writing a better request.
Do these rules work on Replit, Bolt, v0 and Base44?
The shape does. Every one of these builders turns a described outcome into a list of edits, so naming the place and the boundary helps on all of them. The wording of the negative is where they differ: Replit’s tutorial tells you to state what you want rather than what to avoid, while Lovable tells you to write “do not touch login” explicitly. Keep negatives that name a place and drop negatives that name a quality, and the same message works everywhere. What does not carry across is the standing-instruction surface, because project knowledge and workspace knowledge are Lovable’s fields with Lovable’s limits, and each of the others stores its persistent instructions somewhere of its own.
Built it with AI. Can’t get the last part right?
That’s the normal state of an AI-built app, and it’s fixable. I trace what the app actually does, explain what needs changing, and build it if you want me to.
Talk about your app → 
Free 20-minute video call with Bilal.