Lovable Knowledge Is Now Instructions: Set Your Guidance

Lovable Knowledge is now called Instructions: persistent guidance you enter in workspace or project settings. Use workspace Instructions for shared standards and project Instructions for the app you are building, rather than creating a required knowledge.md file. Lovable’s Instructions guide↗ (opens in a new tab) documents both as plain-text fields. Tools like fenbs can keep the approved decisions behind that guidance available when you continue the work in another AI.

Start with a few rules that change how the next edit should work. A short explanation of the app, its users, and an important boundary is easier to check than a long history of every conversation. The goal is useful direction, not a second copy of everything you have discussed.

Where do you enter Instructions in Lovable?

1. Open Workspace settings, then Instructions, to manage guidance shared across the workspace. Workspace owners and admins manage this guidance.
2. Open Project settings, then Instructions, for guidance specific to one app. You need permission to edit that project to update it.
3. Put a few shared standards in the workspace field, then add the app’s purpose, terms, and constraints in the project field.
4. Read both fields together. Remove repeated rules and resolve any disagreement before asking for another change.

These are the settings names in the Instructions guide linked above. That guide also recognizes repository instruction files such as AGENTS.md and CLAUDE.md. You do not need to invent a knowledge.md file to use the settings feature. If your team already maintains repository instructions, check those too so a rule is not saying different things in different places.

Which rules belong at each level?

Ask whether a rule should apply to every app in the workspace. If the answer is yes, make it shared guidance. If it describes a particular app’s customers, data, or design choices, keep it with that app. Lovable documents one shared set of workspace Instructions, so do not use that field for an exception that only one app needs.

The examples are writing suggestions, not default Lovable settings. They show the difference between a standing rule and a single request. For reusable task prompts and acceptance checks, use the separate Lovable prompt library; those prompts answer a different need from persistent Instructions.

What should a useful first version say?

Imagine you are explaining the app to a new teammate. Tell them what the app is for, what words mean, what must stay consistent, and what needs a person’s decision. Prefer something you can observe over a broad request such as “make it professional.” A reviewer should be able to point at a result and say whether a rule was followed.

Purpose: Help customers request an appointment and help staff review requests.
Terms: Requested means submitted. Confirmed means staff have approved the time.
Interface: Use the existing page styles. Write short, plain labels.
Changes: Explain the effect on existing requests before changing their meaning.
Checks: Test a new request, a missing required field, and a staff review.
Uncertainty: Ask before changing an approved business rule.

Replace the example with facts that are true of your app. Do not leave a suggested test in the guidance if nobody can run it. Avoid passwords, private customer records, and pasted conversations; the field needs the rule or conclusion, not the sensitive material that led you to it. Keep temporary investigation details in the current task.

Record who approved a durable rule and why in fenbs’s shared work record. The Instructions field can carry the short direction, while the saved decision explains the reason when another person or AI revisits it.

How do you test whether the guidance is useful?

First ask for an explanation, then try a small edit. Lovable’s Chat mode guide↗ (opens in a new tab) says Chat discusses the current app without changing its code or data. Choose Chat from the mode picker next to the input and ask which Instructions apply to your proposed change. Connected tools are a separate boundary, so do not approve unrelated tool actions during this check.

1. Ask Lovable to restate the app’s purpose and name the rules that apply to one small change.
2. Compare its explanation with the actual Instructions. Correct a vague rule before proceeding.
3. Request a limited edit that exercises the rule, such as changing one confirmation label while preserving its meaning.
4. Review the result yourself and run the checks you named. A correct summary of a rule is not evidence that the resulting app follows it.

When you need an editable plan before implementation, that is the separate Lovable Plan mode workflow. Keep this test narrow: you are checking the guidance, not commissioning a whole app redesign. One clear pass or failure will teach you more than a large change with several possible causes.

Why might a rule still be missed?

Instructions guide the assistant; they do not enforce app permissions or guarantee correct behavior. Lovable says Instructions enter context with each message, project guidance generally takes priority when it is more specific, and following guidance can become inconsistent in very long conversations. Resolve contradictions instead of treating priority as a dependable way to hide a disagreement.

• Too broad: replace “keep the design good” with the actual design choice you want preserved.
• Outdated: remove a rule when the team has approved a replacement, rather than appending the opposite rule below it.
• Wrong scope: move an app-specific exception out of shared workspace guidance.
• Untested: add a concrete check instead of trusting the assistant’s claim that it complied.

Lovable’s debugging guide↗ (opens in a new tab) recommends summarizing a difficult issue and its fix for project Instructions after the problem is solved. Keep the preventive lesson short. A complete error log is usually less helpful than a sentence explaining the mistake to avoid and the check that catches it.

How to keep approved guidance with fenbs

Keep the work so you can carry on from exactly where you left off, on any device and in any other AI. Save the decision that matters, the guidance you tested, and the next check. You do not need to copy every message.

1. Create a free account.
2. Connect Lovable to fenbs.
3. Ask it to record the rules you approved, why they matter, and the small test you ran.
4. Before you stop, ask it to save what passed, what still needs checking, and where to begin next time.
5. When you return, ask your connected AI to read the saved work before making a change.

Lovable documents custom chat connectors↗ (opens in a new tab) for remote MCP servers, a standard way for an AI app to use outside tools. A workspace admin can disable them. fenbs is unnecessary if all you need is one app’s Instructions field; it helps when decisions and progress need to survive across tools and people.

For the wider choice of building tools, see Lovable vs Claude Code. For more ways to write guidance you can reuse, browse prompts and skills for AI work. Keep that exploration separate from the small set of Instructions your current app actually needs.