How long does it take to create a Lovable Skill?

A first working Skill can be built and published in under 30 minutes. More complex Skills with bundled scripts and references typically take 1–3 hours.

Do I need to know how to code to create a Skill?

Basic Skills are just Markdown — no code required. Skills with bundled scripts use TypeScript or Python, but the agent can help write those for you.

Where do I publish my Skill?

Submit your Skill to the public catalog at /submit. Once approved it becomes installable from lovableskills.com by anyone.

Can Skills be private?

Yes — Skills can live inside a single project's .workspace/skills/ directory without being published, which is useful for client-specific or proprietary workflows.

How to Create a Lovable Skill (Step-by-Step Tutorial)

A complete walkthrough — from the empty folder to a published Skill in the catalog. We'll build a tiny but real one: a Skill that adds a Resend-backed contact form to any project.

Before you start

If you're fuzzy on what a Skill actually is, take five minutes with the complete guide and Skills vs Knowledge. The tutorial below assumes you understand the concept and want to ship one. Browse the catalog at /skills for inspiration — copying the shape of a high-rated Skill is faster than designing from scratch.

Step 1 — Scope it down

A great Skill does one thing. Resist the urge to bundle. Our example does exactly: "Add a working Resend-powered contact form with rate limiting." Nothing else. If you find yourself writing "and also handles unsubscribes" in the description, stop — that's a second Skill.

Step 2 — Create the folder

resend-contact-form/
  SKILL.md
  references/
    schema.example.ts
  scripts/
    install.ts

Step 3 — Write SKILL.md

Frontmatter first — the description is how the agent decides to use it:

---
name: Resend Contact Form
description: Adds a Resend-powered contact form with Zod validation, rate limiting, and an admin notification email. Use when the project needs a working contact form.
version: 1.0.0
---

# Instructions
1. Install dependencies: resend, zod
2. Add a server route at /api/contact
3. Add a <ContactForm /> component using react-hook-form + Zod
4. Read RESEND_API_KEY from process.env (request via secrets tool if missing)
5. Apply IP rate limit (5/min) using the project's existing limiter, or add one

Step 4 — Add references

The agent reads referenced files when relevant. Keep them small and concrete: a schema example, a code snippet, a template email. Don't paste your entire codebase — big references dilute retrieval and waste tokens.

Step 5 — Test against real prompts

Install the draft locally and try prompts like:

"Add a contact form to the landing page"
"I need users to email support from /contact"
"Set up a form that emails me when someone submits it"

If any of those don't trigger the Skill, your description is too narrow.

Step 6 — Handle secrets and side effects

Any Skill that needs an API key should request it explicitly via the secrets flow rather than hard-coding or asking the user to paste it into chat. Document everyexternal call the Skill performs: which service, what data leaves the project, whether it costs money per invocation. Users skim — explicit beats clever.

Step 7 — Add a "when not to use" note

One short paragraph telling the agent when to skip your Skill is the single highest- leverage edit you can make. Example: "Don't use this if the project already has a form framework (Formspree, Tally) or if the user wants a multi-step form — this Skill is single-step only." Misfires are the #1 reason Skills get bad ratings.

Step 8 — Publish to the catalog

Submit via /submit. You'll get a public page, install command, version history, and discoverability across the LovableSkills community. Pick a category that matches — the catalog is browsed via /categories at least as often as via search.

Step 9 — Iterate against the leaderboard

Look at how the leaders on the 2026 top 10 structure their descriptions and examples. The shape of those Skills isn't accidental — it's converged on what actually ranks. If you're aiming for the SaaS audience, study the picks in Lovable Skills for SaaS.

Step 10 — Version with intention

Treat your Skill's contract like a public API. Bump the minor version for additive changes (new optional step, extra reference); bump the major version when behavior or outputs change in a way downstream projects would notice. Silent breaking changes erode trust faster than missing features.

Common mistakes

Bundling multiple jobs. Split them — discoverability suffers otherwise.
Vague descriptions. Name the trigger, not the feature.
Untested edge prompts. The agent doesn't read your mind; it reads your description.
No version bump on breaking changes. Downstream projects will silently break.
Hard-coded values. Anything project-specific belongs in Knowledge, not the Skill.
Skipping the "when not to use" note. Cheapest reputation insurance you'll ever buy.