What's the difference between a Lovable Skill and Knowledge?

A Skill teaches the agent a new capability (how to integrate Stripe, how to set up auth). Knowledge teaches the agent facts about your specific project (your brand voice, your database schema, your conventions).

Can I use Skills and Knowledge together?

Yes, and you usually should. Skills handle the 'how', Knowledge handles the 'what for this project'. A Stripe Skill installed alongside Knowledge about your pricing tiers gives you both the capability and the project-specific configuration.

When should I write Knowledge instead of a Skill?

Use Knowledge for anything that only matters in one project: brand guidelines, internal terminology, business rules. Use a Skill when the recipe would help any project doing the same task.

Lovable Skills vs Knowledge: What's the Difference?

Both extend what Lovable can do, but they solve very different problems. Use this guide to decide which one to reach for — and when to use both together.

TL;DR

Skills give Lovable new abilities: a workflow, integration, or procedural know-how it didn't have out of the box.
Knowledge gives Lovable context about your project: facts, design rules, naming conventions, business logic.
Skills change what Lovable can do. Knowledge changes how it does it.

What is a Lovable Skill?

A Skill is a packaged capability: instructions, optional code, and a small contract that tells Lovable how to perform a task end-to-end. Think of it as installing a new tool in the agent's toolbox — Stripe checkout, Resend transactional email, a Supabase RLS audit, an SEO scan. Skills are reusable across projects, versioned independently, and discovered via the catalog at /skills. The full breakdown of how they're structured lives in the complete guide.

What is Project Knowledge?

Knowledge is the always-on context layer for one project: your tone of voice, palette, domain entities, "never use library X", "all amounts are in EUR cents". It steers every response without you re-explaining it each turn. It's invisible — it doesn't show up as a tool the agent calls, it shapes everything the agent already does.

The mental model

Picture a new senior engineer joining your team. Skills are the playbooks pinned to the wall — "this is how we ship checkout, this is how we set up auth". Knowledge is the onboarding doc that explains the company: product, customers, conventions, what we don't do. A great engineer needs both, and so does Lovable.

When to use which

You want…	Use
Stripe checkout in one prompt	Skill
"Our buttons are always rounded-2xl, never rounded-full"	Knowledge
Generate PDF invoices on demand	Skill
"Our company is called Acme, B2B SaaS, EU only"	Knowledge
SEO audit + fixes	Skill
"Voice is matter-of-fact, never marketing-speak"	Knowledge
Spin up a Supabase Auth flow with Google + email	Skill
"All amounts in cents, all dates in ISO, all IDs UUID"	Knowledge

Using them together

The best results come from combining both. A Skill knows how to ship a Stripe integration; Knowledge tells it your pricing tiers, currency, and that VAT must be applied to EU customers. The Skill executes; Knowledge constrains. The same pattern repeats across the stack: a Resend Skill plus Knowledge of your brand voice produces transactional emails that don't feel like every other SaaS. A PostHog Skill plus Knowledge of your funnel produces events that actually map to your KPIs.

Common confusion

"Should I put my API key in Knowledge?" No. Secrets go through the secrets flow, never into Knowledge or Skills. Both are visible to anyone with access to the project.

"Can a Skill read Knowledge?" Implicitly, yes — when a Skill runs, Knowledge is already steering the agent. You don't need to wire them together.

"Where do code conventions go?" Knowledge. Conventions are project- specific. A Skill that hard-codes your conventions is less portable.