From lovable-cloud
Lovable's UI knowledge fields — `.lovable/*.md` repo-mirror workflow, Project/Workspace scope split, precedence, review criteria. TRIGGER when: editing `.lovable/*.md`; drafting Project/Workspace Knowledge changes; reviewing `.lovable/**` PRs. DO NOT TRIGGER when: not a Lovable project; editing CLAUDE.md or AGENTS.md; editing agent rules files; writing code.
How this skill is triggered — by the user, by Claude, or both
Slash command
/lovable-cloud:lovable-cloud-knowledgeThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
| | Workspace Knowledge | Project Knowledge |
| Workspace Knowledge | Project Knowledge | |
|---|---|---|
| Scope | Cross-project (the Lovable workspace) | Single-project |
| Use for | Coding style, naming, libraries/frameworks, architectural patterns, testing requirements, lint rules, brand/voice, Lovable-platform behavior | What the app does, user personas, schema/tables, architecture decisions, domain terminology, project-specific constraints, design specifics, security/compliance, links to important references |
| Precedence | — | Prioritized on conflict |
| Char limit | 10,000 | 10,000 |
When a rule could plausibly fit in either: ask whether it would apply to a different project in the same Lovable workspace. If yes → workspace. If no (it's tied to this product's domain, schema, or constraints) → project.
Project Knowledge is prioritized over Workspace Knowledge on conflict. See REFERENCES.md for the full four-source load priority (Project Knowledge → Workspace Knowledge → AGENTS.md/CLAUDE.md → project code).
.lovable/ repo-mirror workflow.lovable/project-knowledge.md and .lovable/workspace-knowledge.md are
version-controlled mirrors of the corresponding Lovable UI fields.
Lovable only loads the UI fields at runtime; the repo files are not
auto-loaded — they exist for diff review and history.
Workflow for updating Lovable knowledge:
.lovable/ file.Do not assume that writing to .lovable/ propagates to Lovable. The
UI field is the only thing Lovable reads; the repo file is the
authoring/review surface.
Do not skip the repo step and paste directly into the UI without a PR — that loses diff review, version history, and audit trail.
When writing content for either field:
ai-instruction-and-memory-files §3)..lovable/** changesWhen reviewing a PR that touches .lovable/*.md:
workspace-knowledge.md;
this-app-specific → project-knowledge.md. Project knowledge wins
on conflict.project-knowledge.md or
workspace-knowledge.md changed, has the "Last synced" date been
bumped in the same PR? Does the PR description note that the human
needs to paste the merged content into the Lovable UI?Guides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub jcdendrite/claude-config --plugin lovable-cloud