워크스페이스 스킬로 Lovable의 재사용 가능한 온디맨드 워크플로를 정의하세요. 워크스페이스의 모든 프로젝트에서 일치하는 작업이 등장할 때마다 Lovable이 적용하는 집중된 지침·플레이북·체크리스트를 패키지화합니다.
스킬(Skills)은 Lovable에게 반복적인 작업을 처리하는 방법을 가르치는 기능입니다. 한 번만 어떻게 하길 원하는지 말해두면, 같은 종류의 작업이 등장할 때마다 Lovable이 같은 워크플로를 적용합니다.
스킬은 워크스페이스 수준에 존재하는 짧고 이름이 있는 플레이북입니다. 각 스킬에는 이름(name), 언제 사용할지를 Lovable에게 알려주는 설명(description), 스킬이 적용될 때 Lovable이 따라야 할 지침을 담은 본문(instructions)이 있습니다. 각 워크스페이스에는 필요한 만큼 많은 스킬을 둘 수 있습니다.
지식(Knowledge)은 항상 배경 컨텍스트로 로드됩니다. 스킬은 작업이 일치할 때만 로드됩니다. 예를 들어 launch-checklist 스킬은 누군가 Lovable에게 배포를 앞두고 있다고 말할 때만 적용되며, 관련 없는 작업에는 영향을 주지 않습니다.
스킬은 워크스페이스 수준에서 한 번 정의되어 워크스페이스의 모든 프로젝트에 자동으로 공유됩니다.
스킬은 평범한 마크다운 기반 파일입니다. 이동·읽기·편집이 가능하기 때문에 도구 간에 옮기고, Lovable에게 정확히 무엇이 지시되는지 확인하고, 팀원과 공유하고, 시간이 지남에 따라 개선할 수 있습니다.
커스텀 스킬과 빌트인 스킬
Skills 페이지는 두 섹션으로 나뉩니다.
워크스페이스 스킬(Workspace skills) 은 사용자와 팀이 워크스페이스에 추가한 스킬입니다. 모든 프로젝트에 공유되며, 아래의 권한 규칙을 따르고, 이 페이지 나머지의 주된 대상입니다. 채팅에서 작성하거나 GitHub에서 가져오거나 ZIP으로 업로드한 새 스킬이 여기 표시됩니다.
Lovable이 만든 스킬(Skills built by Lovable) 은 Lovable이 유지·관리하며 설정 없이 바로 사용 가능합니다. 스프레드시트나 슬라이드 덱 생성 같은 일반 작업을 다루며 모든 워크스페이스에서 기본으로 제공됩니다. 읽을 수 있고 관련될 때 Lovable이 사용하도록 할 수 있지만, 편집·삭제·다운로드는 할 수 없습니다.
두 종류 모두 슬래시 메뉴에 같은 방식으로 표시되며 Lovable이 자동으로 호출할 수 있습니다.
스킬 vs. 지식
스킬과 지식은 서로 보완합니다.
- 지식은 항상 컨텍스트에 포함됩니다. 코딩 표준, 브랜드 가이드라인, 프로젝트 도메인 용어 등 Lovable이 하는 모든 일에 적용되는 규칙과 컨벤션에 사용하세요.
- 스킬은 요청이 일치할 때 온디맨드로 로드됩니다. 릴리스 체크리스트 실행, 고객 답변 초안 작성, 특정 종류의 콘텐츠 생산 등 특정 작업에만 의미가 있는 지침에 사용하세요.
모든 메시지에 관련된 지침이라면 워크스페이스 지식에 넣으세요. 특정 주제가 등장할 때만 관련된다면 스킬로 만드세요.
스킬은 관련 있을 때만 로드되므로, 모든 대화에 한꺼번에 로드하지 않고도 많은 집중된 스킬을 유지할 수 있습니다.
스킬이 적합한 용도
스킬은 Lovable이 매번 같은 방식으로 반복하길 원하는 작업별 워크플로에 가장 적합합니다. 흔한 용도:
- 배포 직전·출시 직전 체크리스트("이제 배포한다, 체크리스트를 돌려라")
- 반복 콘텐츠 작업(릴리스 노트, 체인지로그 항목, 지원 응답, 마케팅 카피)
- 리뷰 플레이북(랜딩 페이지 리뷰, 카피 리뷰, 접근성 점검)
- Lovable이 온디맨드로 실행할 수 있도록 사내 프로세스 래핑(온보딩 흐름 리뷰, QA 점검, 결제 설정)
- 특정 종류의 콘텐츠에 대한 특정 톤이나 브랜드 페르소나 적용
- 팀이 반복 사용하는 특수 능력(특정 종류의 문서, 파트너 통합, 리서치 루틴)
스킬은 워크스페이스 단위이므로, 모든 프로젝트가 같은 종류의 작업을 같은 방식으로 처리하길 원하는 팀에 특히 유용합니다.
스킬 추가
워크스페이스에 스킬을 추가하는 방법은 세 가지입니다.
채팅에서 스킬 작성
스킬은 Lovable과의 대화에서 만드는 것이 가장 쉽습니다. Lovable이 마음에 드는 방식으로 일을 처리한 후 "save that as a skill" 이라고 말하고 언제 트리거되어야 할지 설명하세요. Lovable이 스킬 초안을 작성해 채팅에 보여줍니다.
초안을 승인할 때까지는 워크스페이스에 아무것도 추가되지 않습니다. 승인하면 스킬이 게시되어 워크스페이스 어디서나 사용 가능합니다.
GitHub에서 가져오기
Settings → Skills 를 열고 Import 를 클릭한 뒤 GitHub 탭을 선택해 공개 GitHub 리포지토리 URL을 붙여넣습니다(예: https://github.com/owner/repo).
Lovable이 리포지토리를 다운로드하고 검증한 뒤 워크스페이스에 스킬을 추가합니다. 리포지토리에는 루트 또는 단일 최상위 폴더 안에 SKILL.md 가 있어야 합니다.
ZIP 업로드
Settings → Skills 를 열고 Import 를 클릭한 뒤 ZIP 탭으로 전환해 .zip 파일을 끌어다 놓거나 찾아 선택합니다. 아카이브에는 루트 또는 단일 래핑 폴더 안에 SKILL.md 가 있어야 합니다. ZIP 업로드는 최대 50 MB 입니다.
스킬 관리
Settings → Skills 에서 워크스페이스의 모든 스킬을 보고, 스킬의 설명과 본문을 편집하거나, 더 이상 필요 없는 스킬을 삭제할 수 있습니다.
같은 페이지가 Project settings → Skills 에서도 제공되며, 거기서는 추가로 해당 프로젝트에 대해 개별 스킬을 비활성화할 수 있습니다. 한 프로젝트에서 스킬을 비활성화해도 다른 프로젝트에 영향을 주지 않으며, 워크스페이스에서 스킬이 삭제되지도 않습니다.
스킬 다운로드
Settings → Skills 에서 커스텀 스킬을 열고 Download 를 클릭해 전체 스킬 패키지를 .zip 으로 내보냅니다. 다운로드는 스킬 백업, 다른 워크스페이스와의 공유, 팀원이 오프라인에서 조정하도록 전달하는 데 사용할 수 있습니다. 다운로드는 모든 워크스페이스 멤버가 사용할 수 있습니다.
프로젝트에서 스킬 활성화·비활성화
모든 워크스페이스 스킬은 기본적으로 모든 프로젝트에서 사용 가능합니다. 특정 프로젝트에서 끄려면 Project settings → Skills 를 열고 스킬을 펼친 뒤 Enable skill 토글을 끄세요. 스킬은 워크스페이스의 다른 곳에서 사용 가능한 상태로 유지되며, 해당 프로젝트에 편집 권한이 있는 사람이 나중에 다시 켤 수 있습니다.
스킬 사용
워크스페이스에 스킬이 존재하면, 요청이 그 설명과 일치할 때마다 Lovable이 자동으로 로드합니다.
같은 워크스페이스에 많은 스킬이 있어도 한꺼번에 로드하지는 않습니다. Lovable은 현재 요청에 관련 있어 보이는 스킬만 로드합니다.
채팅에서 / 를 입력해 스킬을 명시적으로 호출할 수도 있습니다. 워크스페이스의 모든 스킬이 메뉴로 열리며 타이핑할수록 필터링되고, 호버 시 각 스킬의 설명이 표시되어 메시지를 보내기 전 올바른 것을 선택했는지 확인할 수 있습니다.
스킬의 구조
각 스킬에는 세 가지 필수 부분이 있습니다.
- Name(이름): 짧은 식별자, 1~64자. 소문자 알파벳, 숫자, 하이픈만 가능(예:
launch-checklist,release-notes,support-reply). 선행·후행·연속 하이픈은 금지. 이름은 Lovable이 스킬을 내부적으로 참조하는 방식이며 생성 후 변경할 수 없습니다. 이름을 바꾸려면 삭제하고 새로 만드세요. - Description(설명): 이 스킬을 언제 사용할지를 Lovable에게 알려주는 한 문장. "Use when..." 으로 시작해 트리거를 가능한 한 구체적으로 묘사하세요. 설명은 Lovable이 주어진 메시지에서 스킬을 로드할지 결정하는 주된 신호입니다.
- Instructions(지침): 스킬의 본문, 마크다운으로 작성. 스킬이 로드되면 Lovable이 따르는 내용입니다.
좋은 기준은 작업을 처음 수행하는 새 팀원에게 줄 지시처럼 작성하는 것입니다. 무엇을 해야 하고, 무엇을 피해야 하고, 주의할 엣지 케이스, 기대하는 출력 형식.
전체 SKILL.md 는 최대 100,000자까지 가능합니다.
스킬에는 번들 파일(bundled files) 도 포함할 수 있습니다. 더 긴 참조 문서나 지침이 가리키는 작은 스크립트 등 스킬과 함께 이동하는 선택적 추가 파일입니다(예: reference.md). 번들 파일은 스킬을 펼쳤을 때 Bundled files 목록에 표시되며 다운로드나 임포트 시에도 포함됩니다. 채팅에서 작성한 스킬은 보통 번들 파일이 필요 없으며, 번들 파일은 GitHub이나 ZIP에서 가져온 스킬에서 가장 흔합니다.
스킬의 각 파일은 최대 1 MB, 한 스킬은 모든 파일 합쳐 최대 10 MB, 스킬당 최대 200개 파일을 가질 수 있습니다.
잘 작성된 설명은 스킬에서 가장 중요한 부분입니다. 설명이 모호하면 Lovable이 기대하는 때 스킬을 로드하지 않거나 관련 없는 작업에 로드할 수 있습니다.
좋은 설명은 스킬이 언제 적용되어야 하고 언제 적용되지 말아야 할지를 모두 정의합니다. 명확한 경계는 Lovable이 관련 없는 작업에 끌어들이지 않고 올바른 스킬을 일관되게 로드하도록 돕습니다.
좋은 vs. 나쁜 스킬 설명
설명은 Lovable이 스킬을 언제 로드할지 결정하는 방식입니다. 모호한 설명과 정확한 설명의 차이는 스킬이 얼마나 안정적으로 동작하는지에 큰 영향을 줍니다.
너무 모호함
description: Helps with SEO.이 설명은 스킬을 언제 사용해야 할지, 어떤 종류의 SEO 작업에 적용되는지, 실제로 무엇을 해야 할지 명확히 알려주지 않습니다.
구체적이고 범위가 명확함
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.이 설명은 다음을 명시합니다.
- 트리거(기존 페이지 감사),
- 범위(메타데이터, 헤딩, 내부 링크),
- 경계(새 카피 작성은 제외).
범위가 잘 정해진 설명은 스킬이 더 일관되게 로드되게 하고 유사한 스킬 간 충돌을 줄입니다.
예시 스킬
배포를 앞두고 있다고 Lovable에게 말할 때마다 실행되는 사전 출시 체크리스트:
Name
launch-checklistDescription
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.이 스킬은 SKILL.md 와 함께 번들 참조 파일도 포함할 수 있습니다.
launch-checklist/
├── SKILL.md
├── seo-checklist.md
└── accessibility-checklist.md번들 파일을 사용하면 스킬이 자세한 참조·템플릿·도움 자료를 메인 지침과 분리해서 관리할 수 있습니다. 예를 들어 launch-checklist는 더 깊은 SEO·접근성 검증 단계를 SKILL.md 에 모두 넣는 대신 별도 파일로 보관할 수 있습니다.
스킬의 역할 기반 접근
스킬 접근은 워크스페이스·프로젝트 역할을 따릅니다.
| 역할 | 허용되는 작업 |
|---|---|
| 워크스페이스 owner와 admin | 커스텀 워크스페이스 스킬 생성·편집·삭제·임포트(채팅, GitHub, ZIP 모두) |
| 워크스페이스 owner, admin, editor 또는 특정 프로젝트에 Project editor 이상 권한이 있는 사용자 | 해당 프로젝트에 대해 커스텀 워크스페이스 스킬을 활성화 또는 비활성화 |
| 콜라보레이터를 포함한 모든 워크스페이스 멤버 | 모든 스킬 호출·조회·읽기, 커스텀 워크스페이스 스킬 다운로드 |
Enterprise 플랜에서는 스킬 변경이 워크스페이스 감사 로그에 기록됩니다.
모범 사례
- 설명은 트리거로 시작. 설명은 Lovable이 스킬을 적용할지 결정하는 방식입니다. "Use when..." 으로 시작해 어떤 종류의 요청인지 가능한 한 구체적으로 묘사하세요. 모호한 설명의 스킬은 일관되지 않게 로드됩니다.
- 하나의 스킬, 하나의 일. 모든 상황을 다루려는 스킬은 너무 자주 로드되거나 너무 자주 무시됩니다. 광범위한 지침은 여러 집중된 스킬로 나누고 각각이 특정 종류의 작업을 담당하게 하세요.
- 경계와 "피해야 할 것" 섹션 포함. 무엇을 하지 말아야 할지 알려주는 것이 무엇을 해야 할지 알려주는 것만큼 중요합니다. 강한 스킬은 의도된 동작과 피해야 할 동작을 모두 정의합니다.
- "항상 적용" 규칙은 지식에 넣기. 모든 메시지에 적용되는 규칙은 워크스페이스 지식에 속합니다. 스킬은 특정 상황에만 의미 있는 동작용입니다.
- 본문은 짧은 플레이북처럼 작성. 짧은 섹션, 불릿, 직접적인 지시를 사용하세요. 스킬은 Lovable이 읽는 컨텍스트의 일부가 되므로, 짧고 집중된 본문이 길고 산만한 본문보다 더 안정적으로 따라집니다.
- 말로만 하지 말고 보여주기. 도움이 될 곳에 구체적인 값, 예시 카피, 예시 출력을 본문에 포함하세요. Lovable은 추상적인 지시보다 구체적인 지시를 더 안정적으로 따릅니다.
- 검토하고 정리. 워크스페이스가 커질수록 더 이상 필요 없는 스킬은 폐기하세요. 오래되거나 잘못된 지침이 든 스킬은 스킬이 없는 것보다 더 나쁩니다.