Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.lovable.dev/llms.txt

Use this file to discover all available pages before exploring further.

Skills let you teach Lovable how to handle recurring tasks. Tell Lovable once how you want something done, and it applies the same workflow whenever that kind of task comes up. Skills are short, named playbooks that live at the workspace level. Each skill has a name, a description that tells Lovable when to use it, and a body containing the instructions Lovable should follow when the skill applies. Each workspace can hold as many skills as you need. Knowledge is always loaded as background context. Skills are loaded only when the task matches. A launch-checklist skill, for example, only applies when someone tells Lovable they are about to ship. It does not affect unrelated work. Skills are defined once at the workspace level and shared automatically with every project in the workspace. Skills are plain markdown-based files. Because they are portable, readable, and editable, you can move them between tools, inspect exactly what Lovable is being told, share them with teammates, and improve them over time.

​
Custom and built-in skills

The Skills page is split into two sections. Workspace skills are the skills you and your team add to the workspace. They are shared with every project, follow the permission rules below, and are the focus of the rest of this page. New skills you author in chat, import from GitHub, or upload as a ZIP appear here. Skills built by Lovable are maintained by Lovable and ready to use without setup. They cover common tasks like generating a spreadsheet or a slide deck and are available in every workspace by default. You can read them and let Lovable use them when relevant, but you cannot edit, delete, or download them. Both kinds show up the same way in the slash menu and can be invoked automatically by Lovable.

​
Skills vs. knowledge

Skills and knowledge complement each other.
  • Knowledge is always included in context. Use it 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 when the request matches. 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 knowledge. If it is only relevant when a specific topic comes up, make it a skill. Skills are loaded only when relevant, so you can maintain many focused skills without loading them all into every conversation.

​
What skills are for

Skills are best for task-specific workflows that you want Lovable to repeat the same way every time. Common uses include:
  • Pre-launch and pre-ship checklists (“you’re about to launch, run through the checklist”)
  • Recurring content tasks (release notes, changelog entries, support replies, marketing copy)
  • Review playbooks (landing-page reviews, copy reviews, accessibility passes)
  • Wrapping an internal process so Lovable can run it on demand (onboarding flow review, QA pass, billing setup)
  • Applying a specific tone of voice or brand persona for certain kinds of content
  • Specialized capabilities your team uses repeatedly (a particular kind of document, a partner integration, a research routine)
Because skills are workspace-scoped, they are particularly useful in teams where you want every project to handle the same kind of task in the same way.

​
Add a skill

There are three ways to add a skill to your workspace.

​
Author a skill in chat

Skills are most easily created in conversation with Lovable. After Lovable does something well, you can say “save that as a skill” and describe when you want it to trigger. Lovable drafts the skill and surfaces it in chat for you to review. Nothing is added to your workspace until you approve the draft. When you do, the skill is published and available everywhere in the workspace.

​
Import from GitHub

Open Settings → Skills, click Import, choose the GitHub tab, and paste a public GitHub repository URL (for example, https://github.com/owner/repo). Lovable downloads the repo, validates it, and adds the skill to your workspace. The repository must contain a SKILL.md either at its root or inside a single top-level folder.

​
Upload a ZIP

Open Settings → Skills, click Import, switch to the ZIP tab and drag in or browse for a .zip file. The archive must contain a SKILL.md at the root or inside a single wrapping folder. ZIP uploads can be up to 50 MB.

​
Manage your skills

Go to Settings → Skills to see every skill in your workspace, edit a skill’s description and body, or delete a skill you no longer need. The same page is available from Project settings → Skills, where you can additionally disable individual skills for that project. Disabling a skill in one project never affects other projects, and never deletes the skill from the workspace.

​
Download a skill

Open any custom skill in Settings → Skills and click Download to export the full skill package as a .zip. You can use the download to back up a skill, share it with another workspace, or hand it to a teammate to adjust offline. Downloads are available to every workspace member.

​
Enable or disable a skill for a project

Every workspace skill is available in every project by default. To turn one off for a specific project, open Project settings → Skills, expand the skill, and switch off the Enable skill toggle. The skill stays available in the rest of the workspace, and anyone with edit access on that project can switch it back on later.

​
Use a skill

When a skill exists in your workspace, Lovable will load it automatically whenever a request matches its description. You can have many skills in the same workspace without loading them all at once. Lovable only loads the skills that appear relevant to the current request. You can also invoke a skill explicitly by typing / in chat. A menu opens with every skill in your workspace, filtered as you keep typing, with each skill’s description shown on hover so you can confirm you are picking the right one before sending the message.

​
Anatomy of a skill

Each skill has three required parts:
  • Name: a short identifier, between 1 and 64 characters. Lowercase letters, numbers, and hyphens only (for example, launch-checklist, release-notes, support-reply). No leading, trailing, or consecutive hyphens. The name is how Lovable refers to the skill internally and cannot be changed after creation. To rename a skill, delete it and create a new one.
  • Description: a single sentence that tells Lovable when this skill should be used. Start with “Use when…” and describe the trigger as concretely as possible. The description is the main signal Lovable uses to decide whether to load the skill for a given message.
  • Instructions: the body of the skill, written in markdown. This is what Lovable follows once the skill is loaded.
A good rule of thumb is to write the instructions you would give a new teammate performing the task for the first time: what to do, what to avoid, edge cases to watch for, and the format you expect back. The full SKILL.md can be up to 100,000 characters. A skill can also include bundled files: optional extra files that travel with the skill, such as a longer reference document or a small script the instructions point to (for example, reference.md). Bundled files appear in the Bundled files list when you expand the skill, and they are included in any download or import. Skills authored in chat usually do not need bundled files; they are most common for skills imported from GitHub or a ZIP. Each file in a skill can be up to 1 MB, each skill can be up to 10 MB total across all files, and a skill can contain up to 200 files. A well-written description is the most important part of a skill. If the description is vague, Lovable may not load the skill when you expect it to, or may load it for unrelated tasks. Good descriptions define both when the skill should apply and when it should not. Clear boundaries help Lovable load the right skill consistently without pulling it into unrelated tasks.

​
Good vs. bad skill descriptions

Descriptions are how Lovable decides when to load a skill. The difference between a vague description and a precise one has a major impact on how reliably the skill behaves. Too vague 
description: Helps with SEO.
This description does not clearly tell Lovable when to use the skill, what kind of SEO task it applies to, or what it should actually do. Specific and scoped 
description: Use when auditing SEO health on an existing page: checking metadata, heading structure, and internal links. Not for writing new SEO copy from scratch.
This description names:
  • the trigger (auditing an existing page),
  • the scope (metadata, headings, internal links),
  • and the boundary (not for writing new copy).
Well-scoped descriptions make skills load more consistently and reduce conflicts between similar skills.

​
Example skill

A pre-launch checklist that runs whenever you tell Lovable you are about to ship: Name 
launch-checklist
Description 
Use when I say I'm about to launch, ship, share, or release a project, or when I ask whether it is ready to go live. Run the checklist below before giving a go/no-go.
Instructions 
Launch checklist

Before approving the launch, walk through this checklist and report back on each item with pass, fail, or "needs manual check". Do not skip ahead.

Account flows
- Sign-up, sign-in, sign-out, and password reset are wired up end to end.
- Signed-out users cannot reach pages that require an account.
- Signed-in users land on the right page after login.

Core surfaces
- The home page and every primary route render without console errors.
- Every list, table, or feed has a real empty state, not "No data".
- Long-running actions show a loading state and surface errors with a retry path.
- At mobile width (375px) there is no horizontal scroll and primary actions are reachable.

Data and permissions
- Database tables that hold user data have row level security enabled.
- A user in one account cannot read or write another account's data. Flag this as "needs manual check". Ask me to verify with a second test account before launch.
- Destructive actions (delete, cancel, refund) ask for confirmation.

Content and trust
- App name, favicon, social preview image, and meta description are set.
- Footer links to a working privacy policy and terms page.
- No placeholder copy left in the UI ("Lorem ipsum", "TODO", "Your headline here").

Environment
- No dev URLs, localhost references, or test API keys (for example, Stripe `sk_test_*`) in production code.
- Required production environment variables and secrets are set.
- Analytics or product events fire on the actions you want to measure.

Final step
- Summarize anything that failed or needs a manual check, in priority order.
- Do not say "ready to launch" unless every item above passes or has been explicitly waived.
This skill could also include bundled reference files alongside SKILL.md: 
launch-checklist/
├── SKILL.md
├── seo-checklist.md
└── accessibility-checklist.md
Bundled files let a skill keep detailed references, templates, or helper material separate from the main instructions. For example, the launch checklist could keep deeper SEO and accessibility verification steps in separate files instead of putting everything directly into SKILL.md.

​
Role-based access for skills

Access to skills follows your workspace and project roles.
RoleAllowed action
Workspace owner, admin, or editorCreate, edit, delete, and import custom workspace skills (from chat, GitHub, or ZIP)
Workspace owner, admin, or editor, or any user with Project editor or higher access on a specific projectEnable or disable a custom workspace skill for that project
Any workspace member, including collaboratorsView and read all skills, and download custom workspace skills
On Enterprise plans, skill changes are recorded in your workspace audit log.

​
Best practices

  • Lead the description with the trigger. The description is how Lovable decides whether to apply the skill. Start with “Use when…” and describe the kind of request as concretely as you can. Skills with vague descriptions are loaded inconsistently.
  • One skill, one job. A skill that tries to cover every situation will be loaded too often and ignored too often. Split broad guidance into several focused skills and let each one own a specific kind of task.
  • Include boundaries and “avoid” sections. Telling Lovable what not to do is often as important as telling it what to do. Strong skills define both the intended behavior and the behaviors to avoid.
  • Put “always-on” rules in knowledge instead. If a rule should apply to every message, it belongs in workspace knowledge. Skills are for behavior that only matters in specific situations.
  • Write the body like a short playbook. Use short sections, bullet points, and direct instructions. Skills become part of the context Lovable reads, so shorter and more focused bodies are followed more reliably than long ones.
  • Show, do not just tell. Where helpful, include concrete values, example copy, or example outputs in the body. Lovable follows specific instructions more reliably than abstract ones.
  • Review and prune. As your workspace grows, retire skills that are no longer needed. A skill with stale or incorrect instructions is worse than no skill at all.

​
FAQ

The full SKILL.md, including the description and body, can be up to 100,000 characters. Names are limited to 64 characters. A skill can also include bundled files alongside SKILL.md: each file can be up to 1 MB, and a skill can contain up to 200 files totalling 10 MB.
No. The name is set when the skill is created. To rename a skill, delete it and create a new one with the desired name. The description and body can always be edited.
No. The easiest way to create a skill is to ask Lovable in chat. After Lovable does something the way you want, say “save that as a skill” and describe when it should trigger. Lovable drafts the skill and surfaces it in chat for you to review. When you approve the draft, it is added to your workspace.
Type / in the chat. A menu opens with every skill in your workspace, filtered as you keep typing, and shows each skill’s description on hover so you can confirm you are picking the right one. Pick a skill to drop it into your message. You can also just describe what you want, and Lovable will pick up the right skill from its description.
Yes. A skill can ship with extra files alongside its SKILL.md, for example, a longer reference document, a prompt template, or a small script the instructions refer to. These appear under Bundled files when you expand the skill, and travel with the skill when you download or import it. Each file can be up to 1 MB, and a skill can include up to 200 files totalling 10 MB.Bundled files are especially useful for imported GitHub or ZIP-based skills that need larger references, templates, datasets, or helper scripts alongside the main instructions.
Yes. Every skill defined in a workspace is available to every project in that workspace. If a particular skill does not fit a specific project, you can disable it from that project’s settings without affecting other projects.
Yes. Open Project settings → Skills, expand the skill, and switch off the Enable skill toggle. The skill stays enabled in the rest of the workspace, and anyone with edit access on that project can switch it back on later.
Lovable reads the description of each skill and decides whether the skill is relevant to your current request. Clear, specific descriptions produce more reliable behavior. If a skill is not triggering when you expect, rewrite the description to be more explicit about the kind of request it applies to.
Knowledge is always included as background context for Lovable. Skills are loaded on demand when the request matches the skill’s description. Use knowledge for rules that apply to every message, and skills for instructions that only matter for specific kinds of tasks.
Yes. Lovable can use more than one skill in a single message. Keep skills focused so that overlapping skills combine cleanly rather than contradicting each other.
There is no additional cost for creating or using a skill. Standard credits apply to the chat message you send, whether or not a skill is involved.
Skills are stored in your workspace. On Enterprise plans, every edit and deletion is also recorded in the workspace audit log.
A public GitHub repository whose contents include a SKILL.md file. The SKILL.md can be at the root of the repo or inside a single top-level folder. Private repositories and other Git hosts are not supported at launch.
A .zip file (up to 50 MB) with a SKILL.md either at the root of the archive or inside one wrapping folder. Any other files referenced by the skill (the bundled files) should sit alongside SKILL.md in the same directory. Each individual file can be up to 1 MB, and the whole skill can be up to 10 MB with up to 200 files. macOS-specific metadata like __MACOSX/ and .DS_Store at the root is ignored.
Each GitHub repository or ZIP file represents a single skill today. Repeat the import for each skill you want to add.
Yes. Download the skill as a .zip from one workspace, then import the ZIP into another. The imported skill arrives with the same name, description, and contents.
No. Only the skills you have added to the workspace can be downloaded. Lovable-built skills are read-only and managed by Lovable.
Built-in skills are shipped and maintained by Lovable. They cover common tasks Lovable already supports, like creating spreadsheets or slide decks, and are available to every workspace by default. You can see them in the Skills page but cannot edit, delete, or download them.Custom skills are the ones you and your team create. They are stored in your workspace, can be edited or removed at any time, and follow your workspace’s permissions.