{'>'}_
English 繁體中文 日本語 한국어 Deutsch Español Français
Login

Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Claude's capabilities with specialized knowledge, workflows, or tool integrations.

0 stars
0 forks
Python
69 views
View on GitHub Add to Favorites

SKILL.md

name: skill-creator description: Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Claude's capabilities with specialized knowledge, workflows, or tool integrations. license: Complete terms in LICENSE.txt

스킬 생성기

이 스킬은 효과적인 스킬을 생성하기 위한 가이드를 제공합니다.

스킬이란

스킬은 전문 지식, 워크플로우, 도구를 제공하여 Claude의 기능을 확장하는 모듈식 독립 패키지입니다. 특정 도메인이나 작업을 위한 "온보딩 가이드"라고 생각하면 됩니다. 스킬은 Claude를 범용 에이전트에서 어떤 모델도 완전히 갖출 수 없는 절차적 지식을 갖춘 전문 에이전트로 변환합니다.

스킬이 제공하는 것

  1. 전문 워크플로우 - 특정 도메인을 위한 다단계 절차
  2. 도구 통합 - 특정 파일 형식이나 API 작업을 위한 지침
  3. 도메인 전문 지식 - 회사별 지식, 스키마, 비즈니스 로직
  4. 번들 리소스 - 복잡하고 반복적인 작업을 위한 스크립트, 참조 자료, 에셋
  5. 핵심 개념/로직/코드 - 기능별 핵심 원리, 비즈니스 로직, 실제 소스코드 (아래 핵심 로직 및 소스코드 기록 필수 참고)

핵심 원칙

🚨 Reference 문서의 완전성 (최우선 원칙) 🚨

각 기능별 reference 문서는 반드시 다음을 포함하여 완전한 복구/재생성이 가능해야 합니다:

필수 포함 항목 설명
핵심 개념 기능의 근본 원리와 설계 의도
핵심 로직 비즈니스 로직의 정확한 동작 방식
핵심 소스코드 실제 구현된 코드 스니펫
소스코드 파일명 PHP, CSS, JS 등 관련 파일 경로

⛔⛔⛔ 절대 원칙 ⛔⛔⛔

Reference 문서만 보고도 전체 기능을 완벽하게 복구하거나 재생성할 수 있어야 합니다.

이것이 보장되지 않으면 해당 reference 문서는 불완전하며, 반복 작업 시 Claude가 기존 로직을 실수로 변경하거나 손상시킬 위험이 있습니다.

간결함이 핵심

컨텍스트 윈도우는 공공재입니다. 스킬은 Claude가 필요로 하는 모든 것(시스템 프롬프트, 대화 기록, 다른 스킬의 메타데이터, 실제 사용자 요청)과 컨텍스트 윈도우를 공유합니다.

기본 가정: Claude는 이미 매우 똑똑합니다. Claude가 아직 모르는 컨텍스트만 추가하세요. 각 정보에 대해 "Claude가 정말 이 설명이 필요한가?"와 "이 단락이 토큰 비용을 정당화하는가?"를 질문하세요.

장황한 설명보다 간결한 예시를 선호하세요.

적절한 자유도 설정

작업의 취약성과 변동성에 맞게 구체성 수준을 조정하세요:

높은 자유도 (텍스트 기반 지침): 여러 접근 방식이 유효하거나, 결정이 상황에 따라 달라지거나, 휴리스틱이 접근 방식을 안내할 때 사용합니다.

중간 자유도 (의사 코드 또는 매개변수가 있는 스크립트): 선호하는 패턴이 있거나, 약간의 변형이 허용되거나, 구성이 동작에 영향을 미칠 때 사용합니다.

낮은 자유도 (특정 스크립트, 적은 매개변수): 작업이 취약하고 오류가 발생하기 쉽거나, 일관성이 중요하거나, 특정 순서를 따라야 할 때 사용합니다.

Claude를 경로를 탐색하는 존재로 생각하세요: 절벽이 있는 좁은 다리에는 특정 가드레일(낮은 자유도)이 필요하고, 열린 들판에서는 많은 경로(높은 자유도)가 허용됩니다.

스킬의 구조

모든 스킬은 필수 SKILL.md 파일과 선택적 번들 리소스로 구성됩니다:

skill-name/
├── SKILL.md (필수)
│   ├── YAML 프론트매터 메타데이터 (필수)
│   │   ├── name: (필수)
│   │   └── description: (필수)
│   └── 마크다운 지침 (필수)
└── 번들 리소스 (선택)
    ├── scripts/          - 실행 가능한 코드 (Python/Bash 등)
    ├── references/       - 필요에 따라 컨텍스트에 로드되도록 의도된 문서
    └── assets/           - 출력에 사용되는 파일 (템플릿, 아이콘, 폰트 등)

SKILL.md (필수)

모든 SKILL.md는 다음으로 구성됩니다:

  • 프론트매터 (YAML): name과 description 필드를 포함합니다. 이것들은 Claude가 스킬 사용 시기를 결정하기 위해 읽는 유일한 필드이므로, 스킬이 무엇인지, 언제 사용해야 하는지 명확하고 포괄적으로 설명하는 것이 매우 중요합니다.
  • 본문 (마크다운): 스킬 사용을 위한 지침과 안내. 스킬이 트리거된 후에만 로드됩니다 (트리거되는 경우).

번들 리소스 (선택)

스크립트 (scripts/)

결정론적 신뢰성이 필요하거나 반복적으로 다시 작성되는 작업을 위한 실행 가능한 코드 (Python/Bash 등).

  • 포함 시점: 같은 코드가 반복적으로 다시 작성되거나 결정론적 신뢰성이 필요할 때
  • 예시: PDF 회전 작업을 위한 scripts/rotate_pdf.py
  • 장점: 토큰 효율적, 결정론적, 컨텍스트에 로드하지 않고 실행 가능
  • 참고: 스크립트는 패치나 환경별 조정을 위해 Claude가 읽어야 할 수 있음
참조 자료 (references/)

Claude의 프로세스와 사고를 알리기 위해 필요에 따라 컨텍스트에 로드되도록 의도된 문서 및 참조 자료.

  • 포함 시점: Claude가 작업 중 참조해야 할 문서가 있을 때
  • 예시: 재무 스키마를 위한 references/finance.md, 회사 NDA 템플릿을 위한 references/mnda.md, 회사 정책을 위한 references/policies.md, API 사양을 위한 references/api_docs.md
  • 사용 사례: 데이터베이스 스키마, API 문서, 도메인 지식, 회사 정책, 상세 워크플로우 가이드
  • 장점: SKILL.md를 간결하게 유지, Claude가 필요하다고 판단할 때만 로드
  • 모범 사례: 파일이 큰 경우 (>10k 단어), SKILL.md에 grep 검색 패턴 포함
  • 중복 방지: 정보는 SKILL.md 또는 참조 파일 중 한 곳에만 있어야 합니다. 정말로 스킬의 핵심이 아닌 한 상세 정보는 참조 파일을 선호하세요. 이렇게 하면 SKILL.md가 간결해지고 컨텍스트 윈도우를 독점하지 않으면서 정보를 발견할 수 있습니다. 필수적인 절차적 지침과 워크플로우 안내만 SKILL.md에 유지하고, 상세한 참조 자료, 스키마, 예시는 참조 파일로 이동하세요.

🚨🚨🚨 핵심 로직 및 소스코드 기록 필수 (절대 규칙) 🚨🚨🚨

references 폴더의 모든 레퍼런스 문서에는 반드시 다음을 포함해야 합니다:

  1. 핵심 개념 - 해당 기능/도메인의 근본 원리와 설계 의도
  2. 핵심 로직 - 비즈니스 로직의 정확한 동작 방식과 규칙
  3. 핵심 소스코드 - 실제 구현된 코드 스니펫과 사용 예시

왜 이것이 절대적으로 필요한가?

반복적인 작업을 진행할 때 Claude가 실수로 기존 소스코드나 로직을 변경하는 것을 방지하기 위함입니다. 레퍼런스 문서에 핵심 로직과 소스코드가 명확히 기록되어 있으면:

  • ✅ Claude가 기존 패턴을 정확히 따를 수 있음
  • ✅ 일관된 코드 스타일과 구조 유지 가능
  • ✅ 의도치 않은 로직 변경이나 회귀 버그 방지
  • ✅ 새로운 기능 추가 시 기존 코드와의 호환성 보장

⛔ 핵심 로직/소스코드가 없는 레퍼런스 문서는 불완전한 문서입니다! ⛔

🚨🚨🚨 Reference 문서 크기 제한 및 분리 규칙 (필수) 🚨🚨🚨

각 기능별 reference 문서의 최대 라인 수는 1700줄로 제한합니다.

문서가 1700줄을 초과하면 Tree of Thoughts 방식으로 분석하여 서브 카테고리 문서로 분리해야 합니다.

파일 분리 규칙:

원본 파일 분리 후 파일 구조
references/user.md (1700줄 초과) references/user.md (메인 + 요약)
references/user-login.md
references/user-profile.md
references/user-block.md

분리 파일 명명 규칙: references/<main>-<sub>.md

⛔⛔⛔ 메인 문서 요약 필수 규칙 ⛔⛔⛔

분리 시 메인 문서(references/<main>.md)에는 각 서브 문서의 레퍼런스를 100~120단어로 요약해야 합니다.

단순히 "user-login.md 참조"와 같은 짧은 링크가 아니라, **육하원칙(누가, 언제, 어디서, 무엇을, 어떻게, 왜)**에 따라 해당 서브 문서가 포함하는 내용을 구체적으로 설명해야 합니다.

올바른 요약 예시:

### 로그인 관련 → [user-login.md](user-login.md)

Firebase Authentication 기반 사용자 로그인 처리 전체 흐름을 다룹니다.
프론트엔드에서 `firebase_user_ready()`, `database_user_ready()` 콜백 함수를
사용하여 Firebase 인증 상태와 PostgreSQL 사용자 데이터를 순차적으로 로드하는
방법을 설명합니다. 백엔드에서는 `assert_user()` 함수로 Firebase ID Token을
검증하고 사용자 정보를 추출하는 과정을 포함합니다. 또한 `window.state.user`
객체 구조, `window.login` 전역 변수 활용법, Vue.js setup()에서의 로그인
컴포넌트 마운트 패턴을 상세히 기술합니다.

잘못된 요약 예시 (금지):

### 로그인 관련
자세한 내용은 [user-login.md](user-login.md)를 참조하세요.

분리 프로세스:

  1. 원본 문서를 Tree of Thoughts 방식으로 분석하여 논리적 서브 카테고리 식별
  2. 각 서브 카테고리를 독립적인 <main>-<sub>.md 파일로 분리
  3. 메인 문서에 각 서브 문서의 100~120단어 요약 작성
  4. 메인 문서에서 상세 내용 제거 (요약과 링크만 유지)
에셋 (assets/)

컨텍스트에 로드되도록 의도되지 않고, Claude가 생성하는 출력에서 사용되는 파일.

  • 포함 시점: 스킬이 최종 출력에서 사용될 파일이 필요할 때
  • 예시: 브랜드 에셋을 위한 assets/logo.png, PowerPoint 템플릿을 위한 assets/slides.pptx, HTML/React 보일러플레이트를 위한 assets/frontend-template/, 타이포그래피를 위한 assets/font.ttf
  • 사용 사례: 템플릿, 이미지, 아이콘, 보일러플레이트 코드, 폰트, 복사하거나 수정되는 샘플 문서
  • 장점: 출력 리소스를 문서와 분리, Claude가 컨텍스트에 로드하지 않고 파일 사용 가능

스킬에 포함하지 말아야 할 것

스킬은 기능을 직접 지원하는 필수 파일만 포함해야 합니다. 다음을 포함한 불필요한 문서나 보조 파일을 만들지 마세요:

  • README.md
  • INSTALLATION_GUIDE.md
  • QUICK_REFERENCE.md
  • CHANGELOG.md
  • 등등.

스킬은 AI 에이전트가 당면한 작업을 수행하는 데 필요한 정보만 포함해야 합니다. 생성 과정, 설정 및 테스트 절차, 사용자 대상 문서 등에 대한 보조 컨텍스트는 포함하지 않아야 합니다. 추가 문서 파일을 만들면 혼란만 가중됩니다.

점진적 공개 설계 원칙

스킬은 컨텍스트를 효율적으로 관리하기 위해 3단계 로딩 시스템을 사용합니다:

  1. 메타데이터 (name + description) - 항상 컨텍스트에 있음 (~100 단어)
  2. SKILL.md 본문 - 스킬이 트리거될 때 (<5k 단어)
  3. 번들 리소스 - Claude가 필요로 할 때 (스크립트는 컨텍스트 윈도우에 읽지 않고 실행할 수 있어 무제한)

점진적 공개 패턴

컨텍스트 비대화를 최소화하기 위해 SKILL.md 본문을 필수 사항만 유지하고 500줄 미만으로 유지하세요. 이 한도에 근접하면 콘텐츠를 별도 파일로 분리하세요. 콘텐츠를 다른 파일로 분리할 때, 스킬 독자가 파일이 존재하고 언제 사용해야 하는지 알 수 있도록 SKILL.md에서 참조하고 언제 읽어야 하는지 명확히 설명하는 것이 매우 중요합니다.

핵심 원칙: 스킬이 여러 변형, 프레임워크 또는 옵션을 지원할 때, 핵심 워크플로우와 선택 안내만 SKILL.md에 유지하세요. 변형별 세부 사항(패턴, 예시, 구성)은 별도 참조 파일로 이동하세요.

패턴 1: 참조가 있는 고수준 가이드

# PDF 처리

## 빠른 시작

pdfplumber로 텍스트 추출:
[코드 예시]

## 고급 기능

- **양식 작성**: 전체 가이드는 [FORMS.md](FORMS.md) 참조
- **API 참조**: 모든 메서드는 [REFERENCE.md](REFERENCE.md) 참조
- **예시**: 일반적인 패턴은 [EXAMPLES.md](EXAMPLES.md) 참조

Claude는 필요할 때만 FORMS.md, REFERENCE.md 또는 EXAMPLES.md를 로드합니다.

패턴 2: 도메인별 구성

여러 도메인이 있는 스킬의 경우, 관련 없는 컨텍스트 로딩을 피하기 위해 도메인별로 콘텐츠를 구성하세요:

bigquery-skill/
├── SKILL.md (개요 및 탐색)
└── reference/
    ├── finance.md (매출, 청구 지표)
    ├── sales.md (기회, 파이프라인)
    ├── product.md (API 사용량, 기능)
    └── marketing.md (캠페인, 기여도)

사용자가 영업 지표에 대해 물으면 Claude는 sales.md만 읽습니다.

마찬가지로, 여러 프레임워크나 변형을 지원하는 스킬의 경우 변형별로 구성하세요:

cloud-deploy/
├── SKILL.md (워크플로우 + 제공업체 선택)
└── references/
    ├── aws.md (AWS 배포 패턴)
    ├── gcp.md (GCP 배포 패턴)
    └── azure.md (Azure 배포 패턴)

사용자가 AWS를 선택하면 Claude는 aws.md만 읽습니다.

패턴 3: 조건부 세부 사항

기본 콘텐츠를 보여주고 고급 콘텐츠는 링크로 연결:

# DOCX 처리

## 문서 생성

새 문서에는 docx-js를 사용하세요. [DOCX-JS.md](DOCX-JS.md) 참조.

## 문서 편집

간단한 편집의 경우 XML을 직접 수정하세요.

**변경 추적의 경우**: [REDLINING.md](REDLINING.md) 참조
**OOXML 세부 사항의 경우**: [OOXML.md](OOXML.md) 참조

Claude는 사용자가 해당 기능이 필요할 때만 REDLINING.md 또는 OOXML.md를 읽습니다.

중요 지침:

  • 깊이 중첩된 참조 피하기 - 참조는 SKILL.md에서 한 단계 깊이로 유지하세요. 모든 참조 파일은 SKILL.md에서 직접 링크되어야 합니다.
  • 긴 참조 파일 구조화 - 100줄 이상의 파일의 경우, 미리보기 시 Claude가 전체 범위를 볼 수 있도록 상단에 목차를 포함하세요.

스킬 생성 프로세스

스킬 생성은 다음 단계로 진행됩니다:

  1. 구체적인 예시로 스킬 이해하기
  2. 재사용 가능한 스킬 콘텐츠 계획하기 (스크립트, 참조, 에셋)
  3. 스킬 초기화 (init_skill.py 실행)
  4. 스킬 편집 (리소스 구현 및 SKILL.md 작성)
  5. 스킬 패키징 (package_skill.py 실행)
  6. 실제 사용에 기반한 반복

명확한 이유가 없는 한 이 단계를 순서대로 따르세요.

1단계: 구체적인 예시로 스킬 이해하기

스킬의 사용 패턴이 이미 명확하게 이해된 경우에만 이 단계를 건너뛰세요. 기존 스킬 작업 시에도 여전히 유용합니다.

효과적인 스킬을 만들려면 스킬이 어떻게 사용될지에 대한 구체적인 예시를 명확히 이해해야 합니다. 이 이해는 직접적인 사용자 예시나 사용자 피드백으로 검증된 생성 예시에서 올 수 있습니다.

예를 들어, 이미지 편집 스킬을 만들 때 관련 질문은 다음과 같습니다:

  • "이미지 편집 스킬은 어떤 기능을 지원해야 하나요? 편집, 회전, 그 외에?"
  • "이 스킬이 어떻게 사용될지 몇 가지 예시를 들어주실 수 있나요?"
  • "'이 이미지에서 적목 현상 제거해줘'나 '이 이미지 회전해줘' 같은 요청을 상상할 수 있는데요. 이 스킬이 사용될 다른 방법이 있나요?"
  • "사용자가 뭐라고 말해야 이 스킬이 트리거되나요?"

사용자를 압도하지 않기 위해 한 메시지에 너무 많은 질문을 하지 마세요. 가장 중요한 질문부터 시작하고 더 효과적으로 하기 위해 필요에 따라 후속 질문하세요.

스킬이 지원해야 할 기능에 대한 명확한 감각이 있을 때 이 단계를 마무리하세요.

2단계: 재사용 가능한 스킬 콘텐츠 계획하기

구체적인 예시를 효과적인 스킬로 변환하려면 각 예시를 분석하세요:

  1. 처음부터 예시를 어떻게 실행할지 고려
  2. 이러한 워크플로우를 반복적으로 실행할 때 도움이 될 스크립트, 참조, 에셋 식별

예시: "이 PDF 회전해줘" 같은 쿼리를 처리하는 pdf-editor 스킬을 만들 때 분석 결과:

  1. PDF를 회전하려면 매번 같은 코드를 다시 작성해야 함
  2. 스킬에 scripts/rotate_pdf.py 스크립트를 저장하면 도움이 됨

예시: "할 일 앱 만들어줘"나 "걸음 수 추적 대시보드 만들어줘" 같은 쿼리를 위한 frontend-webapp-builder 스킬을 설계할 때 분석 결과:

  1. 프론트엔드 웹앱을 작성하려면 매번 같은 보일러플레이트 HTML/React가 필요함
  2. 보일러플레이트 HTML/React 프로젝트 파일을 포함하는 assets/hello-world/ 템플릿을 스킬에 저장하면 도움이 됨

예시: "오늘 로그인한 사용자가 몇 명이야?" 같은 쿼리를 처리하는 big-query 스킬을 만들 때 분석 결과:

  1. BigQuery를 쿼리하려면 매번 테이블 스키마와 관계를 다시 발견해야 함
  2. 테이블 스키마를 문서화하는 references/schema.md 파일을 스킬에 저장하면 도움이 됨

스킬의 콘텐츠를 확립하려면 각 구체적인 예시를 분석하여 포함할 재사용 가능한 리소스 목록(스크립트, 참조, 에셋)을 만드세요.

3단계: 스킬 초기화

이 시점에서 실제로 스킬을 생성할 때입니다.

개발 중인 스킬이 이미 존재하고 반복이나 패키징이 필요한 경우에만 이 단계를 건너뛰세요. 이 경우 다음 단계로 계속하세요.

새 스킬을 처음부터 만들 때는 항상 init_skill.py 스크립트를 실행하세요. 이 스크립트는 스킬에 필요한 모든 것을 자동으로 포함하는 새 템플릿 스킬 디렉토리를 편리하게 생성하여 스킬 생성 프로세스를 훨씬 더 효율적이고 신뢰할 수 있게 만듭니다.

사용법:

scripts/init_skill.py <skill-name> --path <output-directory>

스크립트는:

  • 지정된 경로에 스킬 디렉토리 생성
  • 적절한 프론트매터와 TODO 플레이스홀더가 있는 SKILL.md 템플릿 생성
  • 예시 리소스 디렉토리 생성: scripts/, references/, assets/
  • 사용자 정의하거나 삭제할 수 있는 각 디렉토리에 예시 파일 추가

초기화 후 생성된 SKILL.md와 예시 파일을 필요에 따라 사용자 정의하거나 제거하세요.

4단계: 스킬 편집

(새로 생성된 또는 기존) 스킬을 편집할 때, 스킬은 다른 Claude 인스턴스가 사용하도록 생성된다는 점을 기억하세요. Claude에게 유익하고 명확하지 않은 정보를 포함하세요. 다른 Claude 인스턴스가 이러한 작업을 더 효과적으로 실행하는 데 도움이 될 절차적 지식, 도메인별 세부 사항 또는 재사용 가능한 에셋이 무엇인지 고려하세요.

검증된 설계 패턴 학습

스킬의 필요에 따라 다음 유용한 가이드를 참조하세요:

  • 다단계 프로세스: 순차적 워크플로우와 조건부 로직은 references/workflows.md 참조
  • 특정 출력 형식 또는 품질 기준: 템플릿과 예시 패턴은 references/output-patterns.md 참조

이 파일들은 효과적인 스킬 설계를 위한 확립된 모범 사례를 담고 있습니다.

재사용 가능한 스킬 콘텐츠로 시작

구현을 시작하려면 위에서 식별한 재사용 가능한 리소스(scripts/, references/, assets/ 파일)로 시작하세요. 이 단계에는 사용자 입력이 필요할 수 있습니다. 예를 들어, brand-guidelines 스킬을 구현할 때 사용자가 assets/에 저장할 브랜드 에셋이나 템플릿, 또는 references/에 저장할 문서를 제공해야 할 수 있습니다.

추가된 스크립트는 버그가 없고 출력이 예상과 일치하는지 확인하기 위해 실제로 실행하여 테스트해야 합니다. 유사한 스크립트가 많으면 모두 작동한다는 확신을 얻으면서 완료 시간과 균형을 맞추기 위해 대표 샘플만 테스트하면 됩니다.

스킬에 필요하지 않은 예시 파일과 디렉토리는 삭제해야 합니다. 초기화 스크립트는 구조를 보여주기 위해 scripts/, references/, assets/에 예시 파일을 생성하지만 대부분의 스킬은 모두 필요하지 않습니다.

SKILL.md 업데이트

작성 지침: 항상 명령형/부정사 형태를 사용하세요.

프론트매터

name과 description으로 YAML 프론트매터를 작성하세요:

  • name: 스킬 이름
  • description: 이것은 스킬의 주요 트리거 메커니즘이며, Claude가 스킬 사용 시점을 이해하는 데 도움을 줍니다.
    • 스킬이 하는 일과 사용할 구체적인 트리거/컨텍스트를 모두 포함하세요.
    • 모든 "사용 시점" 정보를 여기에 포함 - 본문에 넣지 마세요. 본문은 트리거 후에만 로드되므로 본문의 "이 스킬 사용 시점" 섹션은 Claude에게 도움이 되지 않습니다.
    • docx 스킬의 설명 예시: "변경 추적, 댓글, 서식 보존, 텍스트 추출을 지원하는 포괄적인 문서 생성, 편집 및 분석. Claude가 다음을 위해 전문 문서(.docx 파일)로 작업해야 할 때 사용: (1) 새 문서 생성, (2) 콘텐츠 수정 또는 편집, (3) 변경 추적 작업, (4) 댓글 추가, 또는 기타 문서 작업"

YAML 프론트매터에 다른 필드를 포함하지 마세요.

본문

스킬과 번들 리소스 사용을 위한 지침을 작성하세요.

5단계: 스킬 패키징

스킬 개발이 완료되면 사용자와 공유할 배포 가능한 .skill 파일로 패키징해야 합니다. 패키징 프로세스는 모든 요구 사항을 충족하는지 확인하기 위해 먼저 자동으로 스킬을 검증합니다:

scripts/package_skill.py <path/to/skill-folder>

선택적 출력 디렉토리 지정:

scripts/package_skill.py <path/to/skill-folder> ./dist

패키징 스크립트는:

  1. 스킬을 자동으로 검증하여 다음을 확인:

    • YAML 프론트매터 형식 및 필수 필드
    • 스킬 명명 규칙 및 디렉토리 구조
    • 설명의 완전성과 품질
    • 파일 구성 및 리소스 참조

  2. 검증이 통과하면 스킬을 패키징하여, 스킬 이름을 딴 .skill 파일(예: my-skill.skill)을 생성합니다. 이 파일에는 모든 파일이 포함되고 배포를 위한 적절한 디렉토리 구조가 유지됩니다. .skill 파일은 .skill 확장자를 가진 zip 파일입니다.

검증이 실패하면 스크립트가 오류를 보고하고 패키지를 생성하지 않고 종료됩니다. 검증 오류를 수정하고 패키징 명령을 다시 실행하세요.

6단계: 반복

스킬을 테스트한 후 사용자가 개선을 요청할 수 있습니다. 이는 종종 스킬 사용 직후에 발생하며, 스킬이 어떻게 수행되었는지에 대한 신선한 컨텍스트가 있습니다.

반복 워크플로우:

  1. 실제 작업에 스킬 사용
  2. 어려움이나 비효율성 인지
  3. SKILL.md 또는 번들 리소스를 어떻게 업데이트해야 하는지 식별
  4. 변경 구현 및 다시 테스트