Lovable knowledge base: give Lovable a memory with project knowledge, source-of-truth docs and a task backlog

The Lovable knowledge base is the Knowledge feature: two plain text fields, workspace knowledge and project knowledge, that Lovable includes on every message. Lovable's knowledge documentation describes it in one line: "Knowledge lets you provide persistent instructions and context to the Lovable agent." Each field supports up to 10,000 characters, which is enough for rules and a brief but not for a full spec, so the practical setup is a short knowledge field that points to a small set of documents living inside the project.

Why does Lovable drift without a knowledge base?

An AI builder only knows what is in its context for the current message. Without persistent instructions, every new prompt is interpreted against the code as it stands, not against what you decided three days ago. Decisions that never made it into the code, like "volunteers can only see their own shifts" or "no dark mode in version one", get lost first.

Lovable's documentation is candid about the limit even with knowledge in place: "in very long conversations with a lot of context, instructions may not always be followed consistently." Knowledge reduces drift, it does not remove it. The rest of this page is about the operating habits that close the remaining gap.

What goes in Lovable project knowledge?

Project knowledge should read like the first page you would hand a contractor. Lovable's own guide, How to build a real product with Lovable, puts it well: "A good knowledge file reads like a one-page brief, not a wiki." For a PM, that page has four parts:

1. What the product is and who it is for, in two or three sentences.
2. The rules Lovable must never break, such as permissions, data it must not delete, and naming.
3. Design guidance, meaning colours, type, tone and the patterns to avoid.
4. Where the rest of the context lives, and an instruction to read it before every task.

Workspace knowledge is a separate, single field shared by every project in a workspace, and only owners and admins can edit it. Use it for conventions you want everywhere, like "sentence case for all buttons" or "never use placeholder text". When project and workspace knowledge conflict, Lovable's docs say project knowledge is generally prioritised.

Which source-of-truth docs should sit behind the knowledge field?

The 10,000-character cap is why the detail belongs in files. Lovable reads your project knowledge, workspace knowledge and project code before generating edits, so documents kept in a /docs folder in the project are within reach as long as knowledge tells Lovable to open them.

Take a concrete example: a volunteer shift scheduler for a community food bank, where coordinators post shifts and volunteers claim them from their phones. Four documents cover it:

Document	What it answers	Example line for the food bank app
brief.md	What we are building, for whom, and what success means	"Coordinators fill every Saturday shift at least 48 hours ahead without a group chat."
flows.md	Every user journey, step by step	"Volunteer opens the link, sees open shifts this week, taps Claim, gets a confirmation."
design.md	The visual system and the patterns to use or avoid	"Large tap targets, one primary action per screen, no tables on mobile."
build-plan.md	The order features get built and what is out of scope	"Version one: shifts and claims. Not in version one: reminders, reporting."

Keep each one short enough that you would actually reread it. A design spec of 40 bullet points gets ignored by people and by models alike.

How do tasks, rules and a changelog stay current?

Three working files turn the static documents into a system that keeps up with the build:

• tasks.md is the ordered backlog. Every change traces back to a line in it, and finished tasks get checked off rather than deleted.
• decisions.md records choices that are not obvious from the code: "claims are first come, first served; no waitlist", "store times in the food bank's local time zone".
• changelog.md logs what each task added, changed or fixed, so you can see when a regression came in.

The instruction that makes this work goes in project knowledge: before each task, read /docs and tasks.md; after each task, update tasks.md, decisions.md and changelog.md, then report what changed, how to test it, and what comes next. Asking Lovable to confirm which files it read is a cheap way to catch the moment it stops following the setup.

What is the one loop prompt that drives the build?

Once the backlog exists, most of the build is the same prompt, repeated: "Read tasks.md, do the next unchecked group of tasks, check them off, update the changelog, and tell me what to test and what is next." You test, you fix anything wrong with a narrow follow-up, and you run it again.

Larger or riskier groups of tasks go through Plan mode first. Lovable's Plan mode documentation notes that a Plan mode message costs one credit plus any research subagents, and that the working plan is saved to .lovable/plan.md, so a planned change leaves its own written trail next to your docs. If you want the end-to-end build sequence around this loop, from the first prompt to connecting a backend, how to build a prototype with Lovable walks through it.

Is a knowledge base overkill for a small Lovable project?

For a one-screen experiment you will throw away tomorrow, yes. Writing four documents for a landing page mock-up costs more than it saves. The setup starts paying off once a project has more than one user role, a database, or a second working session, because that is when forgotten decisions start producing bugs.

The honest limit is maintenance. Docs that are not updated become a second source of confusion, worse than none, because Lovable follows them confidently. If you are not willing to keep tasks.md and decisions.md current, keep only brief.md and a few rules in project knowledge and accept more drift.

How does this compare with CLAUDE.md or Cursor rules?

The idea is the same across tools: a persistent file of context and rules that the agent reads before acting. Lovable's documentation also states that instruction files such as AGENTS.md or CLAUDE.md can guide its agent, and that a root-level AGENTS.md is always read regardless of session length. If you work across tools, CLAUDE.md for product managers and context files for product specs cover the same pattern elsewhere, and writing a PRD for vibe coding covers how to write the brief that feeds all of it.

Where can you practise this on a real build?

Builders Camp's Building with Lovable bootcamp is a 2-week program with 3 live sessions, directed by Ricardo Luiz, in the Vibe Coding Expert Track. Its published topics include the PM Prompting Framework, Supabase integration, debugging and rollback strategies, and deployment and branding with custom domains, Knowledge Files and GitHub integration. Its practical challenge asks you to help a PM with no developer ship an internal tool in two weeks, including drafting a masterplan file and designing the recurring prompt that drives a task list. See the Building with Lovable bootcamp for dates and format.