Home › Rules › Lovable Project Knowledge
Lovable Project Knowledge template (with examples)
Project Knowledge is the one box Lovable reads on every message. Most people leave it empty or paste in a wall of text. Here's a short, credit-saving version you can fill in in five minutes.
Stack these rules assume: Any Lovable project. These rules go in Project settings → Knowledge. Different stack? Customize it in the generator.
Where these go: Paste the Lovable version into Project settings → Knowledge (up to 10,000 characters). Rules you want in every project go in Workspace Knowledge instead.
Want the full step-by-step kit?
MVP Spec-to-Build Pack ($7): A fill-in 1-page spec, a landing page prompt, a 7-prompt build sequence in the right order, a "did I leak user data?" checklist, and cheap fix-it prompts.
Get the kit for $7 on Gumroad → See what's inside
or get all 5 kits for $25 (save $14) →
One markdown file, instant download. 7-day refund, no questions asked.
Quick start
- Copy the Project Knowledge below.
- In Lovable, open Project settings → Knowledge and paste it.
- Fill in the
[bracketed]lines. Delete any rule that doesn't fit. - Start your next message with: "Follow the project knowledge for this whole session."
Project Knowledge for Lovable (copy this)
Paste it into Project settings → Knowledge. Lovable's limit is 10,000 characters; this version is 2,094. It also works as-is in Bolt's Project Knowledge. It skips the Commands section, since the builder runs the project for you.
# Project rules: Lovable Project Knowledge
Instructions for AI coding agents working on this project. Replace anything in [brackets].
## Project
- What it is: [one sentence: what you are building and who it is for]
- Stack: Any Lovable project. These rules go in Project settings → Knowledge
- Version 1 only needs to: [the ONE thing it must do]
## Project rules
- App facts: it's for [who], they mainly [do what], and the key data is [tables or items]. Don't invent features beyond this.
- Design rules: brand colors [colors], font [font], style [e.g. clean, rounded cards]. Reuse existing components before making new ones.
- Change only what I name in each message. Don't restyle, rename, or reorganize anything else.
- For anything bigger than one small change, describe the plan in a few bullets and wait for my OK.
- If a fix doesn't work the first time, stop and explain the likely cause before trying again.
- If my message conflicts with this Knowledge, ask me which one wins.
## How to work
- Do one task per request. If my request is really several tasks, list them and do only the first.
- Before writing code, give a 3-line plan: what you'll change, which files, and how I'll test it.
- Make the smallest change that works. Don't refactor, rename, or reformat code I didn't ask about.
- Ask before adding a dependency, deleting or moving files, changing the data/database structure, or touching more than 3 files.
- If you're not sure a library, API, or setting exists in the version we use, say so and check the installed package or the docs instead of guessing.
- Never say something works unless you ran it or I confirmed it. Report errors exactly.
- Secrets (API keys, tokens, passwords) live only in environment variables or a .env file listed in .gitignore. Never print, hardcode, or commit them.
- Never run destructive commands (rm -rf, git reset --hard, force-push, dropping tables) without asking first.
## Finish every task with
1. What changed (list the files).
2. How to run or test it in under a minute, and what I should see.
3. A suggested git commit message.
Building this in a browser app builder? These rules work as Project Knowledge in both. Try Lovable · Try Bolt
Disclosure: the Bolt link is an affiliate (referral) link. If you sign up or buy through it, VibeKits may earn a commission at no extra cost to you. The Lovable link is a plain link. It never changes our pick.
Filled-in example: a dog-walking booking app
What the template looks like once the brackets are filled in. Short and specific beats long and vague, and it's still a tiny fraction of the 10,000-character limit.
# Project rules: PawWalk
## Project
- What it is: a booking app where dog owners in one town book walks with local walkers.
- Stack: Lovable, built-in backend (Cloud), built-in auth.
- Version 1 only needs to: let an owner pick a walker and a time slot, and let the walker accept it.
## Project rules
- App facts: it's for dog owners and walkers in one town. Owners book walks; walkers accept or decline. Key data: profiles (owner or walker), dogs, walk_slots, bookings. Don't invent features beyond this.
- Design rules: brand colors #1F6FEB and #FFB020, font Inter, clean white cards with rounded corners. Reuse existing components before making new ones.
- Change only what I name in each message. Don't restyle, rename, or reorganize anything else.
- For anything bigger than one small change, describe the plan in a few bullets and wait for my OK.
- If a fix doesn't work the first time, stop and explain the likely cause before trying again.
- If my message conflicts with this Knowledge, ask me which one wins.
- Not in v1: payments, reviews, chat, maps.
AGENTS.md (if you sync to GitHub or work locally)
Same rules as a file, for when you export the code or keep editing it in Cursor, Codex, Copilot or Claude Code.
# AGENTS.md: Lovable Project Knowledge
Instructions for AI coding agents working on this project. Replace anything in [brackets].
## Project
- What it is: [one sentence: what you are building and who it is for]
- Stack: Any Lovable project. These rules go in Project settings → Knowledge
- Version 1 only needs to: [the ONE thing it must do]
## Project rules
- App facts: it's for [who], they mainly [do what], and the key data is [tables or items]. Don't invent features beyond this.
- Design rules: brand colors [colors], font [font], style [e.g. clean, rounded cards]. Reuse existing components before making new ones.
- Change only what I name in each message. Don't restyle, rename, or reorganize anything else.
- For anything bigger than one small change, describe the plan in a few bullets and wait for my OK.
- If a fix doesn't work the first time, stop and explain the likely cause before trying again.
- If my message conflicts with this Knowledge, ask me which one wins.
## How to work
- Do one task per request. If my request is really several tasks, list them and do only the first.
- Before writing code, give a 3-line plan: what you'll change, which files, and how I'll test it.
- Make the smallest change that works. Don't refactor, rename, or reformat code I didn't ask about.
- Ask before adding a dependency, deleting or moving files, changing the data/database structure, or touching more than 3 files.
- If you're not sure a library, API, or setting exists in the version we use, say so and check the installed package or the docs instead of guessing.
- Never say something works unless you ran it or I confirmed it. Report errors exactly.
- Secrets (API keys, tokens, passwords) live only in environment variables or a .env file listed in .gitignore. Never print, hardcode, or commit them.
- Never run destructive commands (rm -rf, git reset --hard, force-push, dropping tables) without asking first.
## Finish every task with
1. What changed (list the files).
2. How to run or test it in under a minute, and what I should see.
3. A suggested git commit message.
Want the full step-by-step kit?
MVP Spec-to-Build Pack ($7): A fill-in 1-page spec, a landing page prompt, a 7-prompt build sequence in the right order, a "did I leak user data?" checklist, and cheap fix-it prompts.
Get the kit for $7 on Gumroad → See what's inside
or get all 5 kits for $25 (save $14) →
One markdown file, instant download. 7-day refund, no questions asked.
Why each rule exists
- Lovable Project Knowledge ruleApp facts: it's for [who], they mainly [do what], and the key data is [tables or items]. Don't invent features beyond this.Why: Lovable's docs suggest putting the app's purpose, users, and data in Project Knowledge. Facts beat guesses.
- Lovable Project Knowledge ruleDesign rules: brand colors [colors], font [font], style [e.g. clean, rounded cards]. Reuse existing components before making new ones.Why: Without this, every new page gets its own slightly different look.
- Lovable Project Knowledge ruleChange only what I name in each message. Don't restyle, rename, or reorganize anything else.Why: Unrequested "improvements" cost credits and undo work you already approved.
- Lovable Project Knowledge ruleFor anything bigger than one small change, describe the plan in a few bullets and wait for my OK.Why: Lovable's pricing page says Plan mode costs 1 credit per message, while build messages scale with the size of the task. Agreeing on a plan is cheaper than rebuilding.
- Lovable Project Knowledge ruleIf a fix doesn't work the first time, stop and explain the likely cause before trying again.Why: Fix-retry loops are the fastest way to burn through credits.
- Lovable Project Knowledge ruleIf my message conflicts with this Knowledge, ask me which one wins.Why: Knowledge only helps if it's treated as the source of truth, and you stay in charge of exceptions.
- How to workDo one task per request. If my request is really several tasks, list them and do only the first.Why: Big multi-part requests are where AI tools change 12 files and you can't tell which change broke things.
- How to workBefore writing code, give a 3-line plan: what you'll change, which files, and how I'll test it.Why: A plan you can read in 10 seconds catches the wrong approach before it costs you an hour or a pile of credits.
- How to workMake the smallest change that works. Don't refactor, rename, or reformat code I didn't ask about.Why: Drive-by "cleanups" are the #1 cause of "it was working yesterday".
- How to workAsk before adding a dependency, deleting or moving files, changing the data/database structure, or touching more than 3 files.Why: These are the changes that are hard to undo. One quick question is cheaper than a rollback.
- How to workIf you're not sure a library, API, or setting exists in the version we use, say so and check the installed package or the docs instead of guessing.Why: AI tools confidently invent functions and config options. Making it check is the cure.
- How to workNever say something works unless you ran it or I confirmed it. Report errors exactly.Why: "Should work now" isn't a test result. You want facts, not optimism.
- How to workSecrets (API keys, tokens, passwords) live only in environment variables or a .env file listed in .gitignore. Never print, hardcode, or commit them.Why: Leaked keys get found by bots within minutes of a public push. This rule is the cheapest insurance you'll ever buy.
- How to workNever run destructive commands (rm -rf, git reset --hard, force-push, dropping tables) without asking first.Why: One bad command can delete the only copy of your work.
- Finish every task withWhat changed, how to test it, and a commit message.Why: This turns every task into a checkpoint: you test it, you commit it, and you always have a last good version to go back to.
Use it as CLAUDE.md (Claude Code)
Pick one:
- Do nothing. Current Claude Code versions read
AGENTS.mdwhen the project has noCLAUDE.md. Run/memoryin a session to check it loaded. - Import it (best if you want Claude-only extras, or you're on an older Claude Code). Create
CLAUDE.mdnext toAGENTS.md:
@AGENTS.md
## Claude Code
- Use plan mode before any change that touches more than 3 files.
- Claude only? Save the same AGENTS.md text as
CLAUDE.mdinstead. Don't keep two separate copies; they drift apart.
Heads-up: if a project has both files and CLAUDE.md doesn't import AGENTS.md, Claude Code reads only CLAUDE.md by default. More in AGENTS.md vs CLAUDE.md.
Use it as Cursor rules (.cursor/rules/*.mdc)
Cursor reads AGENTS.md too, so the file above already works. If you prefer Cursor's own Project Rules, split it into two .mdc files. The .mdc extension and frontmatter are required; Cursor ignores plain .md files in .cursor/rules.
---
description: Project overview and working rules for Lovable Project Knowledge
alwaysApply: true
---
# Lovable Project Knowledge
Instructions for AI coding agents working on this project. Replace anything in [brackets].
## Project
- What it is: [one sentence: what you are building and who it is for]
- Stack: Any Lovable project. These rules go in Project settings → Knowledge
- Version 1 only needs to: [the ONE thing it must do]
## How to work
- Do one task per request. If my request is really several tasks, list them and do only the first.
- Before writing code, give a 3-line plan: what you'll change, which files, and how I'll test it.
- Make the smallest change that works. Don't refactor, rename, or reformat code I didn't ask about.
- Ask before adding a dependency, deleting or moving files, changing the data/database structure, or touching more than 3 files.
- If you're not sure a library, API, or setting exists in the version we use, say so and check the installed package or the docs instead of guessing.
- Never say something works unless you ran it or I confirmed it. Report errors exactly.
- Secrets (API keys, tokens, passwords) live only in environment variables or a .env file listed in .gitignore. Never print, hardcode, or commit them.
- Never run destructive commands (rm -rf, git reset --hard, force-push, dropping tables) without asking first.
## Finish every task with
1. What changed (list the files).
2. How to run or test it in under a minute, and what I should see.
3. A suggested git commit message.
The project rules only attach when a matching file is in the chat (globs with alwaysApply: false). Want them on all the time? Change it to alwaysApply: true.
---
globs: src/**/*.tsx, src/**/*.ts
alwaysApply: false
---
# Project rules: Lovable Project Knowledge
- App facts: it's for [who], they mainly [do what], and the key data is [tables or items]. Don't invent features beyond this.
- Design rules: brand colors [colors], font [font], style [e.g. clean, rounded cards]. Reuse existing components before making new ones.
- Change only what I name in each message. Don't restyle, rename, or reorganize anything else.
- For anything bigger than one small change, describe the plan in a few bullets and wait for my OK.
- If a fix doesn't work the first time, stop and explain the likely cause before trying again.
- If my message conflicts with this Knowledge, ask me which one wins.
Use either AGENTS.md or these .mdc files, not both, so you don't send the same rules twice. See Cursor rules vs AGENTS.md.
Related
- Best AI tool to build a web app MVP (which tool to use, real prices)
- Lovable vs Bolt vs Replit for beginners (honest picks, real prices)
- AGENTS.md, CLAUDE.md and Cursor rules formats explained
Sources
Checked Oct 19, 2026. These tools change often; if something here no longer matches, tell us at [email protected].