Lovable and AGENTS.md: The Complete 2026 Guide

Lovable builds full web apps from a chat prompt, which makes it a different animal from a CLI coding agent — but the underlying question is the same one every AI coding tool has to answer: how does it know your project’s conventions without you retyping them every message? Lovable’s answer is unusually layered. There isn’t one instruction file — there are four separate context mechanisms, each with its own scope, size limit, and rules for what happens when two of them disagree.

AGENTS.md is a Markdown file that AI coding agents read for project-specific instructions. Lovable’s own docs confirm it directly: “root-level AGENTS.md files are always read by the Lovable agent regardless of session length.” CLAUDE.md works the same way if that’s what your project already has. But in Lovable’s system, that file is only one layer among four.

The Four Layers, in Scope Order

Only one Workspace Knowledge exists per workspace, but every project gets its own Project Knowledge — so a five-project workspace has one shared knowledge base plus five project-specific ones, all potentially active in the same build.

What Goes Where

Lovable’s docs are specific about content, not just mechanics:

Workspace Knowledge (shared across every project):

• Coding style and naming conventions
• Preferred libraries and frameworks
• Shared architectural patterns
• Testing requirements
• Brand voice and UI guidelines

Project Knowledge (specific to one build):

• What the application actually does
• User personas
• Database schema
• Domain-specific terminology
• Architecture decisions unique to this project
• Design guidelines and external references

The split maps cleanly to a real org structure: things a design system team would set once for every project belong in Workspace Knowledge; things only someone building this app would know belong in Project Knowledge.

What Wins When Instructions Conflict

Lovable’s docs give a direct answer for the case where Workspace Knowledge and Project Knowledge disagree: “Lovable is encouraged to prioritize the instructions defined in project knowledge, since they apply specifically to the current project.” Project-specific detail wins over workspace-wide defaults — the same logic as an override file in a more traditional config hierarchy, just implemented as separate knowledge stores instead of nested files.

Skills: On-Demand, Not Always-On

The fourth layer is different in kind, not just scope. Knowledge (workspace or project) is “always included as background,” loaded on every message whether it’s relevant or not. Skills are the opposite — “loaded on demand when the request matches.” A SKILL.md file needs:

• A name: 1–64 characters, lowercase letters/numbers/hyphens only (e.g., launch-checklist)
• A description starting with “Use when…” — this is what Lovable scans to decide relevance before loading the full skill
• The instruction body itself
• Optionally, bundled files: up to 200 files, 10 MB total, 1 MB per file

A full SKILL.md can run up to 100,000 characters — ten times the limit on either Knowledge layer — because it’s only loaded into context when it’s actually needed, not on every single message. Skills are stored at the workspace level (shared across every project, like Workspace Knowledge), split into custom workspace skills your team writes and read-only Lovable-built skills the platform maintains. Triggering is automatic by default — Lovable matches the request against skill descriptions — though you can also invoke one explicitly by typing / in chat and selecting it, with automatic triggering disable-able per skill if you want manual-only control.

A Minimal AGENTS.md Example for Lovable

Lovable’s docs recommend writing instructions like onboarding documentation — specific and actionable, bullet-first, not long prose:

# AGENTS.md

## Stack
- React + TypeScript, Tailwind for styling
- Supabase for auth and Postgres

## Conventions
- Components: PascalCase, one component per file
- No inline styles — Tailwind utility classes only
- Server mutations go through Supabase RPC, not direct table writes

## Do not touch
- `src/lib/design-tokens.ts` — owned by the design team

This is the layer that persists “regardless of session length” per Lovable’s docs — worth remembering if you’ve had a long build session where earlier context seemed to fade. An AGENTS.md instruction doesn’t degrade the way a mid-conversation request might; it’s re-read fresh each time.

FAQ

Q1. Does Lovable read AGENTS.md automatically? Yes. Lovable’s docs state that root-level AGENTS.md files “are always read by the Lovable agent regardless of session length.” CLAUDE.md is read the same way if present instead.

Q2. What’s the difference between Workspace Knowledge and Project Knowledge in Lovable? Workspace Knowledge applies to every project in a workspace and can only be edited by workspace owners/admins; there’s exactly one per workspace. Project Knowledge is specific to a single project, editable by anyone with edit permission on that project, and every project gets its own.

Q3. What happens if Workspace Knowledge and Project Knowledge give conflicting instructions? Lovable’s docs say the agent is “encouraged to prioritize the instructions defined in project knowledge, since they apply specifically to the current project” — project-level detail takes priority over workspace-wide defaults.

Q4. Is there a character limit on Lovable’s Knowledge files? Yes — both Workspace Knowledge and Project Knowledge are capped at 10,000 characters each. Skills have a separate, much larger limit: up to 100,000 characters per SKILL.md.

Q5. How is a Skill different from a Knowledge file in Lovable? Knowledge is always included as background context on every message. Skills load on demand only when the request matches the skill’s description — Lovable’s docs frame this as “the how” (skill) versus your prompt as “the what.” Skills suit recurring, task-specific workflows (launch checklists, release note templates); Knowledge suits rules that should apply to everything.

Q6. Can I import an existing AGENTS.md into Lovable instead of rebuilding my rules? Lovable reads AGENTS.md directly from your project root, so an existing file written for another tool — Claude Code, Cursor, or any other AGENTS.md-compatible agent — works without modification. Skills additionally support importing from a GitHub repo or subdirectory, or uploading a ZIP archive, if you’re migrating existing instructions rather than writing from scratch.

Related Reading on The Prompt Shelf

• AGENTS.md vs CLAUDE.md: Tool Support Compared (2026)
• 15 Best Claude Code Skills 2026
• Does Claude Code Support AGENTS.md? The Complete 2026 Reference
• AGENTS.md Not Loading? How to Debug It in 2026
• Continue.dev and AGENTS.md: Configuration Guide (2026)

Database Schema Belongs in Project Knowledge, Not Credentials

Lovable’s own guidance lists “database schema” as a good candidate for Project Knowledge — table names, relationships, field conventions the agent should respect. What shouldn’t go anywhere near it, or your AGENTS.md, is the actual connection string or service-role key for that database. 1Password CLI’s op run keeps those out of every file Lovable — or any teammate with project edit access — can read, injecting them at deploy or runtime instead of leaving them sitting in a Knowledge field.