워크스페이스 스킬을 사용해 Lovable을 위한 재사용 가능하고 온디맨드인 워크플로를 정의합니다. 집중된 지침, 플레이북, 체크리스트를 패키징하여 워크스페이스의 모든 프로젝트에서 일치하는 작업이 나타날 때마다 Lovable이 적용하도록 합니다.
스킬로 재사용 가능한 지침 정의
워크스페이스 스킬을 사용해 Lovable을 위한 재사용 가능하고 온디맨드인 워크플로를 정의합니다. 집중된 지침, 플레이북, 체크리스트를 패키징하여 워크스페이스의 모든 프로젝트에서 일치하는 작업이 나타날 때마다 Lovable이 적용하도록 합니다.
스킬을 통해 Lovable에게 반복되는 작업을 처리하는 방법을 가르칠 수 있습니다. 워크스페이스 수준에서 한 번 스킬을 정의하면 Lovable이 해당 워크스페이스의 모든 프로젝트에서 사용할 수 있습니다.
각 스킬은 짧고 명명된 플레이북이며 다음을 포함합니다:
- 이름
- Lovable이 언제 사용할지 알려주는 설명
- 스킬이 적용될 때 Lovable이 따르는 markdown 지침
/ 명령으로 프롬프트와 함께 스킬을 호출하거나, 작업이 일치할 때 Lovable이 자동으로 적용하도록 할 수 있습니다.
스킬은 휴대 가능한 markdown 기반 파일이므로 Lovable에게 무엇을 알려주는지 정확히 검사하고, 팀원과 공유하고, GitHub 또는 ZIP에서 가져오고, 시간이 지나면서 개선할 수 있습니다.
스킬과 지식
스킬과 지식은 상호 보완적입니다.
- 지식(Knowledge)은 항상 컨텍스트에 포함됩니다. 코딩 표준, 브랜드 가이드라인, 또는 프로젝트의 도메인 용어와 같이 Lovable이 하는 모든 일에 적용되는 규칙과 관례에 사용하세요.
- 스킬은 요청이 일치할 때 온디맨드로 로드됩니다. 릴리스 체크리스트 실행, 고객 회신 초안 작성, 또는 특정 유형의 콘텐츠 제작과 같이 특정 종류의 작업에만 중요한 지침에 사용하세요.
지침이 모든 메시지에 관련된다면 워크스페이스 지식에 두세요. 특정 주제가 나올 때만 관련된다면 스킬로 만드세요.
스킬은 관련이 있을 때만 로드되므로 모든 대화에 모두 로드하지 않고도 집중된 스킬을 많이 유지할 수 있습니다.
커스텀 및 내장 스킬
Skills 페이지는 두 섹션으로 나뉩니다: Workspace skills와 Skills built by Lovable.
Workspace skills는 팀이 추가한 커스텀 스킬입니다. 워크스페이스의 모든 프로젝트와 공유되며 아래 권한 규칙을 따릅니다. 채팅에서 빌드하거나, 수동으로 작성하거나, GitHub에서 가져오거나, ZIP으로 업로드한 스킬이 여기에 나타납니다.
Skills built by Lovable은 Lovable에서 유지하며 설정 없이 모든 워크스페이스에서 사용할 수 있습니다. 접근성 검사, 리디자인, SEO 리뷰, 스킬 생성, 비디오 생성 같은 일반적인 작업을 커버합니다. 관련이 있을 때 사용할 수 있지만 편집, 삭제, 다운로드할 수는 없습니다.
워크스페이스 스킬과 Lovable-built 스킬은 슬래시 메뉴에 나타나고, 직접 호출할 수 있으며, 요청이 스킬과 일치할 때 자동으로 적용될 수 있습니다.
스킬의 용도
스킬은 반복 가능하고 작업별인 워크플로에 가장 잘 작동합니다. Lovable이 매번 같은 종류의 작업을 같은 방식으로 처리하기를 원할 때 사용하세요.
일반적인 예:
- 출시 검사: 출시 전 체크리스트, 릴리스 준비도 리뷰, go/no-go 리뷰
- 반복 콘텐츠: 릴리스 노트, changelog 항목, 지원 회신, 마케팅 카피
- 리뷰 플레이북: 랜딩 페이지 리뷰, 카피 리뷰, 접근성 패스, 검색 엔진 최적화 리뷰
- 내부 프로세스: 온보딩 흐름 리뷰, 품질 보증 패스, 청구 설정, 파트너 핸드오프 단계
- 작업별 스타일 가이드: 톤 오브 보이스, 브랜드 페르소나, 또는 특정 종류의 콘텐츠에 대한 포맷팅 규칙
- 재사용 가능한 팀 워크플로: 리서치 루틴, 문서 템플릿, 파트너 통합, 또는 기타 반복되는 팀 프로세스
스킬은 워크스페이스 전반에서 공유되므로 모든 프로젝트가 동일한 프로세스를 따르도록 하려는 경우 특히 유용합니다.
스킬에 대한 역할 기반 접근
스킬에 대한 접근은 워크스페이스 및 프로젝트 역할을 따릅니다.
| 역할 | 허용된 작업 |
|---|---|
| 워크스페이스 owner와 admin만 |
|
|
|
Enterprise 플랜에서는 스킬 변경이 워크스페이스 감사 로그에 기록됩니다.
스킬 추가
워크스페이스 owner와 admin은 다섯 가지 방법으로 커스텀 스킬을 추가할 수 있습니다. 네 가지 옵션은 Settings → Skills → Add에서 사용 가능하고, 한 가지는 Lovable이 재사용하고 싶은 작업을 한 후 프로젝트 채팅에서 시작합니다.
Lovable과 함께 빌드
가이드된 스킬 빌딩 대화를 시작하려면 Add → Build with Lovable을 선택합니다. Lovable이 시작 프롬프트와 함께 대시보드를 엽니다:
Help me create a skill together using /skill-creator. First ask me what the skill should do.프롬프트를 보내고 스킬이 무엇을 해야 하는지, 언제 트리거되어야 하는지, 어떤 지침을 따라야 하는지에 대한 Lovable의 질문에 답합니다. Lovable이 스킬을 초안화합니다. 초안을 승인하면 스킬이 워크스페이스에 게시됩니다.
수동으로 작성
처음부터 스킬을 작성하려면 Add → Write manually를 선택합니다.
폼에는 세 개의 필드가 있습니다:
- Name:
launch-checklist또는support-reply같은 짧고 영구적인 ID. 소문자, 숫자, 하이픈만 사용합니다. - Description: Lovable이 스킬을 언제 로드할지 결정하는 트리거. "Use when..."으로 시작하여 스킬의 범위와 경계를 설명합니다.
- Content: 스킬이 로드되면 Lovable이 따르는 지침(단계, 제약, 예시, 예상 출력 등).
게시하려면 Add skill을 클릭합니다. 스킬은 즉시 워크스페이스 전반에서 사용 가능합니다.
필드 요구사항, 명명 규칙, 설명 예시는 스킬의 구조를 참조하세요.
GitHub에서 가져오기
Add → Import from GitHub를 선택하고 공개 GitHub 리포지토리 URL을 붙여넣습니다.
Lovable은 두 가지 GitHub URL 형식을 지원합니다:
- 전체 리포지토리:
https://github.com/owner/repo
리포지토리에 하나의 스킬이 포함될 때 사용합니다.SKILL.md파일은 리포지토리의 루트에 있어야 합니다. - 하위 디렉토리:
https://github.com/owner/repo/tree/<branch>/path/to/skill
단일 리포지토리에 여러 스킬이 포함될 때 사용합니다. 링크된 디렉토리에는SKILL.md가 직접 포함되어야 합니다. 직접 파일 URL도 작동합니다:https://github.com/owner/repo/blob/<branch>/path/to/SKILL.mdblobURL을 사용하면 Lovable이SKILL.md를 포함하는 상위 폴더를 가져옵니다.
Lovable은 리포지토리를 다운로드하고, 검증하고, 스킬을 워크스페이스에 추가합니다.
ZIP 업로드
Add → Upload ZIP을 선택하고 .zip 또는 .skill 파일을 드래그하거나 찾아봅니다. 아카이브에는 루트 또는 하나의 래핑 폴더 내부에 SKILL.md 파일이 포함되어야 합니다. 스킬이 참조하는 번들 파일은 동일한 디렉토리의 SKILL.md 옆에 있어야 합니다.
업로드된 아카이브는 최대 50 MB까지 가능합니다. 각 개별 번들 파일은 최대 1 MB이고, 전체 스킬 패키지는 총 10 MB의 최대 200개 파일을 포함할 수 있습니다. __MACOSX/와 .DS_Store 같은 macOS 메타데이터 파일은 루트에서 무시됩니다.
예시: Claude에서 스킬 가져오기
Lovable의 스킬은 Anthropic의 Claude 및 Agent Skills 규칙을 따르는 다른 도구와 동일한 SKILL.md 형식을 사용합니다. Claude에서 이미 스킬을 빌드한 경우 .skill 또는 .zip 파일로 내보낸 다음 Settings → Skills → Add → Upload ZIP에서 Lovable에 업로드하세요.
Lovable은 아카이브를 검증하고 이름, 설명, 지침, 번들 파일이 그대로 포함된 스킬을 워크스페이스에 게시합니다. 거기서 다른 워크스페이스 스킬처럼 동작합니다.
반대 방향으로도 작동합니다: Lovable에서 커스텀 스킬을 .zip으로 다운로드한 다음 동일한 SKILL.md 형식을 지원하는 다른 도구에 업로드합니다.
프로젝트 채팅에서 저장
성공적인 프로젝트 채팅 상호 작용을 프로젝트를 떠나지 않고 재사용 가능한 스킬로 전환할 수 있습니다. Lovable이 원하는 방식으로 작업을 완료한 후 "save that as a skill"이라고 말하고 스킬이 적용되어야 할 시점을 설명합니다.
Lovable이 이름, 설명, 지침을 포함한 스킬을 초안화한 다음 검토할 수 있도록 채팅에 표시합니다. 초안을 승인하면 스킬이 워크스페이스에 게시됩니다.
스킬 사용
Lovable은 두 가지 방식으로 스킬을 사용할 수 있습니다: 자동으로, 또는 직접 호출할 때.
Lovable이 자동으로 선택하도록 하기
요청이 스킬의 설명과 일치하면 Lovable이 해당 스킬을 자동으로 적용할 수 있습니다. 특별한 작업을 할 필요 없이 원하는 것을 설명하면 됩니다.
동일한 워크스페이스에 많은 스킬을 유지할 수 있습니다. Lovable은 현재 요청에 관련되어 보이는 스킬만 로드합니다. 예를 들어 launch-checklist 스킬은 누군가 Lovable에게 출시할 예정이라고 말할 때만 적용됩니다. 관련 없는 작업에는 영향을 주지 않습니다.
워크스페이스 admin이 스킬의 자동 사용을 비활성화한 경우 작업이 일치하더라도 Lovable이 자동으로 적용하지 않습니다. 슬래시 명령(/skill-name)으로 수동으로 스킬을 호출할 수는 있습니다. 자세한 내용은 자동 사용 활성화 또는 비활성화를 참조하세요.
스킬을 직접 호출
채팅에서 /를 입력하고, 메뉴에서 스킬을 선택한 다음 요청을 계속 입력합니다. 스킬은 메시지 시작 부분에 태그로 나타나 Lovable에게 어떤 지침을 적용할지 알려 줍니다.
스킬을 **방법(how)**으로, 프롬프트를 **무엇(what)**으로 생각하세요.
예를 들어 워크스페이스에 launch-checklist 스킬이 있다면 다음을 보낼 수 있습니다:
/launch-checklist Review the app for launch blockers before Friday's release.입력하는 동안 슬래시 메뉴가 필터링되고 호버 시 각 스킬의 설명을 표시하여 올바른 스킬을 선택하고 있는지 확인할 수 있습니다.
메시지를 보낸 후 스킬이 채팅에 태그로 나타납니다. 태그 위에 마우스를 올려 설명을 보거나, 클릭해 전체 스킬 미리보기를 열거나, 미리보기의 연필 아이콘을 사용해 해당 스킬의 설정을 엽니다.
자동 사용이 비활성화된 스킬도 슬래시 메뉴에 나타나며 /skill-name으로 직접 호출할 수 있습니다. 자동 사용 비활성화는 Lovable이 스스로 스킬을 적용하지 못하게 막을 뿐 스킬을 숨기거나 수동 호출을 차단하지 않습니다.
스킬 관리
워크스페이스 스킬을 관리하려면 Settings → Skills를 사용합니다. 프로젝트에서 작업하는 동안 Project settings → Skills를 열 수도 있습니다. 사용 가능한 액션은 역할에 따라 다릅니다. 스킬에 대한 역할 기반 접근을 참조하세요.
스킬 편집 또는 삭제
Settings → Skills로 이동해 워크스페이스의 모든 스킬을 봅니다. 커스텀 스킬을 열어 설명이나 지침을 편집하거나 더 이상 필요하지 않다면 삭제합니다.
스킬을 삭제하면 워크스페이스와 해당 워크스페이스의 모든 프로젝트에서 제거됩니다.
스킬 다운로드
Settings → Skills에서 커스텀 스킬을 열고 Download를 클릭해 전체 스킬 패키지를 .zip으로 내보냅니다.
다운로드를 사용해 스킬을 백업하고, 다른 워크스페이스로 이동하고, 오프라인 편집을 위해 팀원과 공유하거나, Claude처럼 동일한 SKILL.md 형식을 지원하는 다른 도구에 업로드합니다.
자동 사용 활성화 또는 비활성화
모든 커스텀 워크스페이스 스킬은 기본적으로 Automatic use가 활성화되어 있습니다. 자동 사용이 활성화되면 작업이 일치할 때마다 Lovable이 자동으로 스킬을 적용할 수 있으며 슬래시 명령(/skill-name)으로 수동으로 호출할 수도 있습니다.
자동 사용이 비활성화되면 Lovable은 작업이 일치하더라도 어떤 프로젝트에서도 스스로 스킬을 적용하지 않습니다. 스킬은 워크스페이스에 계속 사용 가능합니다. 슬래시 메뉴에 나타나며 슬래시 명령으로 수동으로 호출할 수 있습니다.
워크스페이스 owner와 admin은 Settings → Skills 또는 프로젝트에서 작업하는 동안 Project settings → Skills에서 스킬의 자동 사용을 활성화하거나 비활성화할 수 있습니다. 이 설정은 전체 워크스페이스에 적용됩니다.
스킬의 구조
각 스킬에는 세 개의 필수 부분이 있습니다.
- Name: 스킬의 짧고 영구적인 식별자(1-64자 사이). 소문자, 숫자, 하이픈만 사용합니다(예:
launch-checklist,release-notes,support-reply). 이름은 하이픈으로 시작하거나 끝날 수 없고 연속된 하이픈을 포함할 수 없습니다. 이름은 생성 후 변경할 수 없습니다. 스킬 이름을 바꾸려면 삭제하고 새로 만드세요. - Description: Lovable이 스킬을 언제 사용할지 알려주는 짧은 문장. "Use when..."으로 시작하여 트리거를 가능한 한 구체적으로 설명합니다. 설명은 Lovable이 메시지에 대해 스킬을 로드할지 결정하는 주요 신호입니다.
- Instructions: 스킬이 로드되면 Lovable이 따르는 markdown 본문. Lovable이 따라야 할 단계, 제약, 예시, 엣지 케이스, 출력 형식을 포함하세요.
좋은 경험 법칙은 작업을 처음 수행하는 새 팀원에게 줄 지침을 작성하는 것입니다: 무엇을 해야 하는지, 무엇을 피해야 하는지, 무엇을 주의해야 하는지, 어떤 형식으로 반환해야 하는지.
전체 SKILL.md 파일은 최대 100,000자까지 가능합니다.
번들 파일
스킬에는 번들 파일도 포함될 수 있습니다. 이는 스킬과 함께 이동하는 선택적 추가 파일입니다. 지침이 가리키는 더 긴 참조, 템플릿, 또는 작은 스크립트(예: reference.md)에 번들 파일을 사용합니다.
번들 파일은 스킬을 펼칠 때 Bundled files 목록에 나타나며 스킬을 다운로드하거나 가져올 때 포함됩니다. 채팅에서 작성된 스킬은 일반적으로 번들 파일이 필요하지 않습니다. GitHub 또는 ZIP에서 가져온 스킬에서 가장 일반적입니다.
각 번들 파일은 최대 1 MB까지 가능합니다. 스킬은 모든 파일에 걸쳐 총 10 MB의 최대 200개 파일을 포함할 수 있습니다.
명확한 스킬 설명 작성
잘 작성된 설명은 스킬에서 가장 중요한 부분입니다. 설명은 Lovable에게 스킬을 언제 로드할지 알려 줍니다.
설명이 모호하면 Lovable이 예상할 때 스킬을 로드하지 않거나 관련 없는 작업에 로드할 수 있습니다. 좋은 설명은 스킬이 언제 적용되어야 하는지와 언제 적용되지 않아야 하는지를 모두 정의합니다. 명확한 경계는 Lovable이 관련 없는 작업에 끌어들이지 않고 일관되게 올바른 스킬을 로드하는 데 도움이 됩니다.
너무 모호함
description: Helps with SEO.이 설명은 Lovable에게 스킬을 언제 사용할지, 어떤 종류의 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 옆에 번들 참조 파일도 포함될 수 있습니다.
예를 들어 출시 체크리스트는 모든 것을 SKILL.md에 직접 넣는 대신 더 깊은 검색 엔진 최적화 및 접근성 검증 단계를 별도의 번들 파일에 유지할 수 있습니다.
launch-checklist/
├── SKILL.md
├── seo-checklist.md
└── accessibility-checklist.md모범 사례
- 트리거로 시작. 설명을 "Use when..."으로 시작하고 요청을 가능한 한 구체적으로 설명합니다. 설명은 Lovable이 스킬을 로드할지 결정하는 방식입니다.
- 각 스킬에 하나의 작업을 부여. 너무 많은 것을 다루려는 스킬은 잘못된 상황에서 로드되거나 Lovable에게 명확한 가이드를 제공하지 못할 수 있습니다. 광범위한 가이드를 집중된 스킬로 분할하고, 각각이 특정 작업을 소유하도록 합니다.
- 경계와 "피해야 할 것" 섹션 포함. Lovable에게 무엇을 하지 말아야 하는지 알려주는 것은 무엇을 해야 하는지 알려주는 것만큼 중요합니다. 강력한 스킬은 의도된 동작과 피해야 할 동작을 모두 정의합니다.
- 항상 켜져 있는 규칙은 지식에 둠. 규칙이 모든 메시지에 적용되어야 한다면 워크스페이스 지식에 속합니다. 스킬은 특정 상황에서만 중요한 동작을 위한 것입니다.
- 짧은 플레이북처럼 지침 작성. 짧은 섹션, 글머리표, 직접적인 지침을 사용합니다. 스킬은 Lovable이 읽는 컨텍스트의 일부가 되므로 더 짧고 집중된 지침을 따르기 더 쉽습니다.
- 말하지 말고 보여줌. 도움이 되는 경우 구체적인 값, 예시 카피, 또는 예시 출력을 포함합니다. Lovable은 추상적인 지침보다 구체적인 지침을 더 안정적으로 따릅니다.
- 검토하고 정리. 워크스페이스가 커지면 더 이상 필요하지 않은 스킬을 폐기합니다. 오래되거나 잘못된 지침이 있는 스킬은 스킬이 없는 것보다 나쁩니다.