Instructions

Instructions (previously Knowledge) let you provide persistent guidance and context to the Lovable agent. Instead of repeating the same explanations in every conversation, you can define them once and Lovable will consider them when generating edits. Instructions are defined at three levels:

Workspace instructions define shared rules that apply across all projects in a workspace, such as coding standards, preferred libraries, or naming conventions.
Project instructions add context that is specific to a single project, such as the application purpose, database schema, architecture decisions, or domain terminology.
Personal instructions are your own rules and preferences, set separately in each workspace you belong to. Only you can see them.

All three are plain text fields that provide persistent instructions to the Lovable agent.

Skills vs. instructions

Skills and instructions complement each other.

Instructions are always included in context. Use them for rules and conventions that apply to everything Lovable does, such as coding standards, brand guidelines, or your project’s domain terminology.
Skills are loaded on demand. Use them for instructions that only matter for specific kinds of tasks, such as running a release checklist, drafting a customer reply, or producing a particular kind of content.

If an instruction is relevant on every message, put it in workspace instructions. If it is only relevant when a specific topic comes up, make it a skill.

Workspace instructions

Workspace instructions are a text field that lets you define shared rules once and apply them across all projects in your workspace. Project instructions can then add context that is specific to a particular project. Use them for rules and conventions that should be consistent across multiple projects. By defining these guidelines once, you avoid repeating the same instructions in every project’s instructions. Workspace instructions are especially useful in team environments where multiple people are building projects. Workspace admins can define guardrails such as coding standards, testing requirements, or architectural rules so every project follows the same conventions automatically. Only workspace owners and admins can manage workspace instructions. To manage workspace instructions, go to either:

Workspace settings → Instructions
Project settings → Instructions

Workspace instructions support up to 10,000 characters.

What to include in workspace instructions

Workspace instructions are best for:

Coding style conventions
Naming conventions
Preferred libraries or frameworks
Shared architectural patterns
Testing requirements
Code quality or linting rules
Language or formatting preferences
Brand voice, UI copy, or design guidelines
Things Lovable should avoid doing

Workspace instructions example

Coding standards
- Always enable TypeScript strict mode.
- Never use `any`. Use `unknown` and narrow the type.
- Prefer named exports. Do not use default exports.
- Prefer `const` over `let`. Never use `var`.

Naming conventions
- Use camelCase for variables and functions.
- Use PascalCase for components and types.
- Use kebab-case for file names.

Styling
- Use Tailwind CSS for styling.
- Do not use inline styles.
- Do not use CSS modules.

Libraries
- Use shadcn/ui components when possible.
- Use React Query for server state.
- Use Zustand for client state.

Architecture
- Route API calls through a service layer.
- Do not call `fetch` directly from React components.

Testing
- Write unit tests for new utility functions and hooks.
- Run existing tests after making changes.
- Verify new functionality in the browser before marking it complete.

Code quality
- Run the linter after significant changes.
- Remove unused imports and dead code.

Localization
- Write code comments and variable names in English.
- Use date format DD/MM/YYYY.
- Use European number formatting (comma as decimal separator).

Brand voice
- Use a friendly, professional tone in all user-facing copy.
- Use sentence case for headings and buttons (for example, "Create new project", not "Create New Project").
- Do not use placeholder text like "Lorem ipsum", always write realistic copy.

General rules
- Do not add `console.log` statements.
- Do not use deprecated React patterns.
- Write code comments in English.

Important notes

Changes apply immediately
If you update workspace instructions during an active conversation, Lovable will use the updated instructions on follow-up messages.
One set of workspace instructions per workspace
Each workspace has a single set of workspace instructions shared across all projects. You cannot define different workspace-level instructions for subsets of projects inside the same workspace.
Workspace instructions in long conversations
Workspace instructions are always included together with project instructions alongside project code and other context sources. However, in very long conversations with a lot of context, instructions may not always be followed consistently.

Project instructions

Project instructions are a text field that stores persistent instructions and context for a single project. Use it to provide information that applies only to that specific project, such as the application purpose, architecture, or domain terminology. Anyone with permission to edit the project can update project instructions. To manage project instructions, go to Project settings → Instructions. Project instructions support up to 10,000 characters.

What to include in project instructions

Good project instructions usually include:

What the application does
User personas or target audiences
Database schema or key tables
Architecture decisions
Domain terminology
Project specific constraints
Design guidelines (colors, typography, or layout)
Links to important references such as API documentation or internal tools
Security or compliance requirements

Project instructions example

Project overview
This is a B2B SaaS application for restaurant managers to track food inventory across multiple locations.

Users
Primary users are restaurant managers who need quick visibility into stock levels and ingredient usage.
Secondary users are staff responsible for logging inventory changes.

Key database tables
- inventory_items (id, name, category, quantity, unit, location_id)
- locations (id, name, workspace_id)
- transactions (id, item_id, quantity_change, type, created_at)

Design guidelines
- Use Tailwind CSS for styling.
- Follow the existing color palette and spacing scale.
- Use consistent spacing and layout patterns across pages.
- Prefer shadcn/ui components when available.

Architecture rules
- Store monetary values in cents as integers.
- Use optimistic updates for all mutations.
- Place reusable components in /components.

Domain terminology
- "Inventory item" refers to a tracked ingredient or product.
- "Transaction" represents a change in inventory quantity.

External references
- API documentation: https://docs.example.com/api

Personal instructions

Personal instructions are your own rules and preferences for Lovable. Each workspace you belong to has a separate set, and Lovable follows them in every project you open in that workspace. Your teammates never see them. Looking for named playbooks that Lovable loads only when a task matches? See personal skills. Personal instructions are available on all plans, and you do not need a workspace admin role to set them. To manage your personal instructions, go to Account settings → Personal instructions and choose the workspace at the top of the page. The field starts empty in every workspace you join. Personal instructions support up to 10,000 characters. Only you can change your personal instructions, and Lovable does not change them. When instructions conflict, Lovable will generally prioritize your personal instructions, then project instructions, then workspace instructions. Clearing the field and selecting Update deletes your personal instructions. Deleting them cannot be undone, so copy anything you want to keep before you clear the field.

What to include in personal instructions

Personal instructions are best for:

How you want Lovable to address you
How much detail you want in a reply
Coding style you prefer for your own work
Libraries and tools you reach for
Approaches you want Lovable to avoid
When you want Lovable to ask before building

Personal instructions example

Communication
- Keep explanations short. Show me the change, not a summary of it.
- Tell me when you are unsure instead of guessing.
- Ask before building when two approaches are both reasonable.

My coding preferences
- Prefer named exports. Do not use default exports.
- Keep components small and move logic into hooks.
- Write comments only where the reason is not obvious from the code.

Best practices

Define shared rules at the workspace level

Use workspace instructions to define coding standards, preferred libraries, architectural conventions, and other rules that should apply across multiple projects.Then use project instructions to add context specific to each project, such as the application purpose, database schema, domain terminology, or integrations.If a project needs different behavior from the workspace defaults, you can define those rules in project instructions. When the same instruction appears in both places, Lovable will generally prioritize project instructions, since it is more specific to the current project. Lovable will generally prioritize your own personal instructions ahead of both.

Be specific

Clear instructions produce better results.Good example:

Always enable TypeScript strict mode. Never use any.

Less useful example:

Write clean code.

Write it like onboarding documentation

Imagine explaining the project to a new developer joining the team. Include the important architectural decisions so Lovable does not attempt to change them.

Keep instructions concise

Short instructions work better than long paragraphs. Prefer bullet lists and direct rules.

Review instructions periodically

If your stack or architecture changes, update your instructions so Lovable does not follow outdated patterns.You do not need to document everything. Even a few clear rules or a short project description can significantly improve the quality of edits.

FAQ

What is the character limit for instructions?

Project instructions, workspace instructions, and personal instructions each support up to 10,000 characters.

Can I have multiple sets of workspace instructions?

No. Each workspace has one set of workspace instructions shared across all projects.

Can I add instruction files in the project's repository?

Yes. Lovable also takes guidance from instruction files such as AGENTS.md or CLAUDE.md in your project.Lovable reads any AGENTS.md or CLAUDE.md file at the top level of your project with every message you send.Lovable reads an instruction file in a subfolder, such as src/components/AGENTS.md, when it opens or edits a file in that folder or a folder inside it.On paid plans, Lovable also rewrites or removes a rule in an AGENTS.md file that no longer matches your code, unless you asked for that rule. See Dreaming.

Which context sources does Lovable read?

When you send a message, Lovable reads your project instructions, workspace instructions, your own personal instructions, 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.Lovable also uses what it remembers about the project and about you. See Memory.

What happens if project and workspace instructions conflict?

Project instructions and workspace instructions are included together when Lovable generates responses.If the instructions conflict, Lovable will generally prioritize the instructions defined in project instructions, since they apply specifically to the current project.Lovable will generally prioritize your own personal instructions ahead of both.To avoid confusion, keep shared rules in workspace instructions and project-specific details in project instructions.

What is the difference between a skill and instructions?

Instructions are always included as background context for Lovable. Skills are loaded on demand when the request matches the skill’s description. Use instructions for rules that apply to every message, and skills for instructions that only matter for specific kinds of tasks.

Getting started

Build

Connect

Collaborate

Deploy & host

Grow & optimize

Workspace & account

Plans & billing

Guides & reference