스킬 | VM0

스킬은 팀이 특정 종류의 업무를 어떻게 하는지 Zero에게 가르치는, 이름이 붙은 재사용 가능한 절차입니다.

Zero에게 처음 무언가를 요청할 때는 프롬프트를 작성합니다. 두 번째에는 같은 프롬프트를 약간 손봐서 붙여넣을 수도 있습니다. 세 번째쯤 되면 누군가 "팀 프롬프트 라이브러리"라고 부르는 Notion 문서에서 긴 프롬프트를 복사하고 있을 겁니다. 그 순간이 그것을 스킬로 만들 때입니다.

스킬이 해결하는 문제

일회성 작업에는 일회성 채팅이면 충분합니다. 하지만 거의 모든 팀에는 반복되는 업무 — 입력은 다르지만 형태는 같은 — 가 쌓여 있습니다.

고객이 문의함 → 이력 조회 → 그들의 언어로 답장 초안 작성 → 티켓 기록
버그 리포트가 나타남 → 재현 단계 추출 → 심각도 분류 → 구조화된 이슈 등록
월요일 아침 → 지난주 수치 수집 → 전주와 비교 → 요약 게시

스킬이 없으면 이 각각은 모두가 기억해야 하는 200단어 프롬프트입니다. 스킬이 있으면 슬래시 명령이 됩니다. /triage-bug-report, /weekly-metrics, /customer-reply.

모든 스킬은 앞에 /가 붙은 이름을 가집니다. 시각적 스킬 선택기는 로드맵에 있습니다 — 지금은 스킬을 만들고, 에이전트에게 그것이 존재한다고 알려주면, 에이전트가 그때부터 그것을 사용합니다.

언제 스킬을 만드는가

솔직한 규칙은 이렇습니다. 실질적으로 같은 프롬프트를 두 번 넘게 작성했다면 — 또는 팀원이 그것을 작성하는 모습을 상상할 수 있다면 — 그것은 스킬입니다.

구체적인 신호들:

그 업무에 팀이 이미 쓰는 이름이 있음("아침 브리핑", "경쟁사 스캔")
프롬프트가 매 실행마다 바뀌면 안 되는 특정 도구, 채널, 템플릿을 언급함
출력이 고정된 형태를 가짐(요약, 초안, 등록된 이슈)
팀의 여러 사람이 그것을 실행해야 함
그것을 스케줄로 실행하고 싶음

스킬 안에 무엇이 있는가

스킬은 세 개의 섹션을 가진 짧은 마크다운 문서입니다.

Description. 이 스킬이 언제 적용되는지 Zero에게 알려주는 한 줄 요약. Zero는 들어오는 요청을 설명과 대조하므로 표현이 중요합니다 — "고객 대면 버그 리포트를 분류하고 심각도와 함께 GitHub에 등록"이 "버그 관련 일 해줘"보다 낫습니다.
Body. 절차 그 자체. 평이한 산문으로 충분합니다. 의사코드는 필요 없습니다. Zero가 사용해야 할 도구, 출력 형태, 제약을 언급하세요. 본문은 잘 작동했던 원래 채팅 프롬프트와 많이 닮았습니다.
Allowed connectors (선택). 제한 목록 — 이 스킬이 Slack과 GitHub만 건드리게 하려면 그것들을 나열하세요. 기본적으로 스킬은 워크스페이스에 연결된 무엇이든 사용할 수 있습니다.

그게 전부입니다. 노드 그래프도, YAML 설정도, 트리거 섹션도 없습니다.

채팅에서 스킬 작성하기

가장 빠른 길은 먼저 채팅에서 프롬프트를 작성하고, 작동하게 만든 다음, 승격시키는 것입니다. Zero가 이를 대신 해줄 수 있습니다.

"마지막 대화를 triage-bug-report라는 재사용 가능한 스킬로 만들어줘. 설명은 간결하게."

Zero는 이렇게 합니다.

대화를 다시 읽음
절차를 추출
설명을 제안
스킬을 워크스페이스에 저장
나중에 사용할 수 있는 정식 이름을 알려줌

표현을 다듬고 싶으면 워크스페이스의 Skills 페이지에서 저장된 스킬을 편집하세요.

Zero가 스킬을 고르는 방법

스킬을 이름으로 호출할 필요는 없습니다. Zero는 들어오는 요청이 설명과 일치하면 스킬을 자동으로 로드합니다. 그래서 *"우리의 목소리와 문서를 사용해 고객 이메일에 답장 초안 작성"*이라는 설명으로 customer-reply-draft라는 스킬을 작성했다면, 고객 이메일을 전달하는 것만으로 — 또는 *"이 고객에게 답장 초안 작성해줘"*라고 말하는 것만으로 — 이름을 대지 않아도 그 스킬이 실행됩니다.

특정 스킬을 강제하고 싶으면 명시적으로 언급하세요. "이 이메일에 customer-reply-draft 스킬을 사용해줘."

내장 스킬

모든 Zero 에이전트는 VM0가 미리 넣어 둔 다양한 직능의 스킬 모음을 함께 제공받습니다 — 리서치와 분석, 재무와 회계, 법무와 컴플라이언스, 제품, 마케팅, 고객 지원, 팀 커뮤니케이션을 아우릅니다. 이것들은 커넥터 워크플로가 아니라 도메인 절차입니다. 각각은 반복되는 종류의 업무를 처리하는 법을 Zero에게 가르칩니다.

각각은 직접 호출할 수 있는 슬래시 명령입니다. 몇 가지 예:

/deep-dive — 구조화된 리서치와 솔루션 설계. 사실을 수집한 다음 선택지를 탐색
/prd-writing — 구조화된 문제 정의와 수용 기준을 갖춘 제품 요구사항
/copywriting — 여러 채널에 걸친 마케팅 카피(블로그, 이메일, 소셜, 랜딩 페이지)
/competitor-matrix — 기능 비교 매트릭스, 포지셔닝 분석, 승패 분석
/customer-reply — 채널과 긴급도에 맞춘 공감적이고 브랜드에 부합하는 답장
/nda-screening — 들어오는 NDA를 GREEN / YELLOW / RED로 분류하고 라우팅
/status-updates — 어떤 청중에게든 맞춘 진행 보고와 이해관계자 업데이트

팀 전체에 스킬 공유하기

스킬은 개인이 아니라 워크스페이스 범위입니다. 스킬을 한 번 저장하면 워크스페이스의 모든 멤버가 사용할 수 있습니다. 별도의 "게시" 단계는 없습니다.

이는 중요합니다. 유용한 스킬을 처음 작성한 사람이 팀 전체에 그 역량을 준다는 뜻입니다. 잘 이름 붙여진 열 개의 스킬을 가진 다섯 명의 팀은 각 작업을 개별적으로 처리하는 팀보다 상당히 빠르게 움직입니다.

흔한 패턴

반복해서 나타나는 몇 가지 형태:

인테이크 폼. 입력 조각(이메일, 버그 리포트, 스레드)을 받아 구조화된 아티팩트(이슈, 초안, 행)를 생성하는 스킬.
주기 브리핑. 매일 또는 매주 실행되어 눈에 띄는 곳에 게시하는, 스케줄과 짝을 이룬 스킬.
대화 중 도우미. 채널에서 @Zero로 트리거되어 집중된 하위 작업(조회, 요약, 분류)을 하는 스킬.
컴포저. 한 번의 실행으로 다중 포맷 묶음 — 블로그 초안 + 소셜 게시물 + 카드 — 을 생성하는 스킬.

피해야 할 함정

너무 좁은 스킬. 하나의 특정 입력에만 맞는 스킬은 취약합니다. 입력의 세부가 아니라 업무의 형태를 겨냥하세요.
너무 모호한 스킬. *"마케팅 도와줘"*는 너무 광범위해서 Zero가 언제 적용할지 모릅니다. 설명에서 구체적으로 하세요.
자격 증명을 하드코딩하는 스킬. 스킬 본문에 API 키를 붙여넣지 마세요. 대신 커스텀 커넥터를 사용하세요.
출력 형태를 묻어 버리는 스킬. 아티팩트가 어떤 모습이어야 하는지 명시적으로 밝히세요 — "세 항목의 번호 목록" 또는 "150단어 미만의 답장 초안".

다음 단계

스킬을 스케줄에 올려 당신이 입력하지 않아도 실행되게 하세요.
권한을 통해 스킬이 어떤 커넥터를 건드릴 수 있는지 제한하세요.
엔드투엔드로 작성된 스킬은 Example workflows를 참조하세요.