자동 스킬 크리에이터로 Claude 코드 스킬 자동 생성 방법

요약

Claude 코드 스킬은 특정 워크플로를 위해 Claude의 기능을 확장하는 사용자 정의 기능입니다. 스킬 생성기 시스템은 구조화된 프로세스를 통해 스킬 생성을 자동화합니다. 즉, 스킬의 목적을 정의하고, SKILL.md 파일을 초안 작성하고, 테스트 사례를 만들고, 정량적 벤치마크로 평가를 실행하며, 피드백을 기반으로 반복적으로 개선합니다.

소개

매일 Claude 코드를 사용하고 있습니다. 프로젝트 구조를 설정하고, 특정 테스트 명령을 실행하고, 특정 방식으로 출력을 포맷하는 등 동일한 시퀀스를 반복하는 자신을 발견합니다. 매번 워크플로를 처음부터 설명합니다. Claude가 기억한다면 어떨까요? 그 워크플로를 한 번 캡처하고 영원히 사용할 수 있다면 어떨까요? 그것이 바로 Claude 코드 스킬이 하는 일입니다. Claude의 기능을 특정 워크플로에 맞게 확장하기 위해 생성하는 사용자 정의 기능입니다. 그리고 스킬 생성기를 사용하면 이 프로세스가 자동화되고 체계적으로 이루어집니다.

이 가이드는 전체 프로세스를 안내합니다. 스킬의 구성, 생성 워크플로, 평가 시스템, 그리고 안정적인 트리거링을 위해 최적화하는 방법을 배우게 됩니다. Anthropic 공식 스킬 저장소의 실제 작동 예시를 볼 수 있습니다.

💡

API 관련 스킬을 구축하는 경우 Apidog가 자연스럽게 통합됩니다. 단일 스킬 워크플로 내에서 API 엔드포인트를 테스트하고, 응답을 검증하고, 문서를 생성할 수 있습니다.

버튼

Claude 코드 스킬이란?

Claude 코드 스킬은 특정 도메인 또는 워크플로를 위해 Claude의 기능을 확장하는 전문화된 지시 세트입니다. 마크다운 파일에 상주하는 사용자 정의 플러그인이라고 생각하면 됩니다.

스킬 시스템 아키텍처

스킬은 3단계 로딩 시스템을 사용합니다:

메타데이터 (~100단어) - 이름 및 설명, 항상 컨텍스트에 포함
SKILL.md 본문 (<500줄) - 핵심 지시사항, 스킬이 트리거될 때 로드됨
번들 리소스 (무제한) - 스크립트, 참조, 필요할 때 로드되는 자산

skill-name/
├── SKILL.md (필수)
│   ├── YAML frontmatter (이름, 설명)
│   └── 마크다운 지시사항
└── 번들 리소스 (선택 사항)
    ├── scripts/    - 반복 작업에 대한 실행 가능한 코드
    ├── references/ - 필요에 따라 로드되는 문서
    └── assets/     - 템플릿, 아이콘, 글꼴

스킬 트리거 시점

스킬은 이름과 설명과 함께 Claude의 available_skills 목록에 나타납니다. Claude는 해당 설명을 기반으로 스킬을 참조할지 여부를 결정합니다.

중요: 스킬은 Claude가 직접 처리할 수 없는 작업에 대해서만 트리거됩니다. "이 파일 읽기"와 같은 간단한 쿼리는 설명이 일치하더라도 스킬을 트리거하지 않습니다. 복잡하고 다단계 워크플로는 설명이 일치할 때 안정적으로 트리거됩니다.

Anthropic 저장소의 실제 예시

스킬	목적	주요 기능
skill-creator	새로운 스킬 생성	테스트 케이스 생성, 벤치마크 평가, 설명 최적화
mcp-builder	MCP 서버 구축	Python/Node 템플릿, 평가 프레임워크, 모범 사례
docx	Word 문서 생성	python-docx 스크립트, 템플릿 시스템, 스타일링 가이드
pdf	PDF 추출 및 조작	양식 처리, 텍스트 추출, 참조 문서
frontend-design	웹 인터페이스 구축	컴포넌트 라이브러리, Tailwind 패턴, 접근성 검사

스킬 생성 워크플로

스킬 생성 프로세스는 체계적인 루프를 따릅니다:

의도 포착 - 스킬이 무엇을 해야 하는가?
초안 작성 - SKILL.md 파일 생성
테스트 케이스 생성 - 현실적인 프롬프트 정의
평가 실행 - 스킬 사용 여부에 따라 실행
결과 검토 - 정성적 피드백 + 정량적 지표
반복 - 발견 사항을 기반으로 개선
설명 최적화 - 트리거 정확도 최대화
패키징 - .skill 파일로 배포

각 단계를 살펴보겠습니다.

1단계: 의도 포착

스킬이 달성하려는 목표를 이해하는 것부터 시작합니다. 이미 수행 중인 워크플로를 캡처하는 경우, 대화 기록에서 패턴을 추출합니다.

다음 네 가지 질문을 해보세요:

이 스킬은 Claude가 무엇을 할 수 있도록 해야 하는가? 결과에 대해 구체적으로 설명합니다.
이 스킬은 언제 트리거되어야 하는가? 어떤 사용자 문구나 컨텍스트에서?
예상 출력 형식은 무엇인가? 파일, 코드, 보고서?
테스트 케이스를 설정해야 하는가? 검증 가능한 출력(코드 생성, 데이터 추출, 파일 변환)이 있는 스킬은 테스트 케이스의 이점을 얻습니다. 주관적인 출력(글쓰기 스타일, 디자인)이 있는 스킬은 종종 필요하지 않습니다.

예시: API 테스트 스킬

의도: 개발자가 REST API를 체계적으로 테스트하도록 돕기
트리거: 사용자가 API 테스트, 엔드포인트, REST, GraphQL을 언급하거나 API 응답을 검증하고자 할 때
출력: 통과/실패 상태, curl 명령, 응답 비교가 포함된 테스트 보고서
테스트 케이스: 예 - 출력은 객관적으로 검증 가능함

2단계: SKILL.md 파일 작성

모든 스킬은 YAML frontmatter와 마크다운 지시사항이 포함된 SKILL.md 파일로 시작합니다.

스킬 구성

---
name: api-tester
description: REST API를 체계적으로 테스트하는 방법. 사용자가 API 테스트, 엔드포인트, REST, GraphQL을 언급하거나 API 응답을 검증하고자 할 때 사용합니다. 테스트가 관련될 때마다 이 스킬을 제안해야 합니다.
compatibility: curl 또는 HTTP 클라이언트 도구 필요
---

# API 테스터 스킬

## 핵심 워크플로

API를 테스트할 때는 다음 단계를 따릅니다:

1. **엔드포인트 이해** - 사양을 읽거나 스키마를 요청합니다
2. **테스트 케이스 설계** - 해피 패스, 엣지 케이스, 오류 조건
3. **테스트 실행** - 요청에 curl 또는 Apidog 사용
4. **응답 검증** - 상태 코드, 헤더, 본문 구조 확인
5. **결과 보고** - 증거와 함께 통과/실패 요약

## 테스트 케이스 템플릿

각 엔드포인트에 대해 다음을 테스트합니다:

- 올바른 페이로드를 사용한 유효한 인증
- 필수 필드가 누락된 유효한 인증
- 유효하지 않은 인증 (401 예상)
- 속도 제한 동작
- 로드 하의 응답 시간

## 출력 형식

항상 보고서를 다음과 같이 구성합니다:

# API 테스트 보고서

## 요약
- 실행된 테스트: X
- 통과: Y
- 실패: Z

## 실패한 테스트

### 테스트 이름
**예상:** 200 OK
**실제:** 400 Bad Request
**응답:** {...}

## 권장 사항
...

작성 모범 사례

점진적 공개 사용: SKILL.md를 500줄 이하로 유지합니다. 자세한 참조는 별도의 파일로 이동합니다.

api-tester/
├── SKILL.md (워크플로 개요)
└── references/
    ├── authentication.md
    ├── rate-limiting.md
    └── response-codes.md

이유 설명: 규칙만 나열하지 마세요. 왜 중요한지 설명하세요.

## 오류 사례를 먼저 테스트하는 이유

해피 패스 전에 오류 조건을 테스트하면 문제의 80%를 더 빨리 해결할 수 있습니다.
인증이 조용히 실패하면 해피 패스 테스트는 의미가 없어집니다.
401 확인부터 시작하세요.

명령형 사용: "항상 상태 코드를 먼저 검증합니다"이지 "상태 코드를 검증해야 합니다"가 아닙니다.

예시 포함: 입력 및 예상 출력을 보여줍니다.

## 커밋 메시지 형식

**예시:**
입력: JWT 토큰으로 사용자 인증 추가
출력: feat(auth): JWT 기반 인증 구현

3단계: 테스트 케이스 생성

스킬 초안을 작성한 후 2-3개의 현실적인 테스트 프롬프트를 생성합니다. 이는 실제 사용자가 만들 수 있는 종류의 요청입니다.

테스트 케이스 형식

테스트 케이스를 evals/evals.json에 저장합니다:

{
  "skill_name": "api-tester",
  "evals": [
    {
      "id": 1,
      "prompt": "api.example.com의 /users 엔드포인트를 테스트합니다 - Bearer 토큰이 필요하며 id, name, email 필드를 가진 사용자 목록을 반환합니다",
      "expected_output": "인증 실패, 성공, 페이지네이션 테스트를 포함한 최소 5개의 테스트 케이스가 있는 테스트 보고서",
      "files": []
    },
    {
      "id": 2,
      "prompt": "새로운 POST /orders 엔드포인트가 잘못된 수량을 올바르게 처리하는지 확인해야 합니다",
      "expected_output": "음수, 0, 비숫자 수량을 적절한 오류 응답과 함께 전송하는 테스트 케이스",
      "files": ["openapi.yaml"]
    }
  ]
}

좋은 테스트 프롬프트란

나쁜 예시: "이 API를 테스트해봐"

좋은 예시: "제 팀이 방금 https://api.stripe.com/v1/charges에 이 새로운 결제 엔드포인트를 배포했는데, 엣지 케이스를 확인해야 해요. 특히 음수 금액이나 존재하지 않는 통화 코드를 보냈을 때 어떤 일이 발생하는지 궁금합니다. 문서에는 400을 반환해야 한다고 되어 있지만 실제 오류 메시지를 보고 싶어요"

좋은 테스트 프롬프트에는 다음이 포함됩니다:

구체적인 URL
구체적인 시나리오
예상 동작
실제 컨텍스트

실행하기 전에 테스트 케이스를 사용자에게 공유하세요: "시도해보고 싶은 몇 가지 테스트 시나리오가 있습니다. 괜찮아 보이시나요, 아니면 더 추가하고 싶으신가요?"

4단계: 평가 실행

이것이 스킬 생성기의 강점입니다. 각 테스트 케이스를 두 번 실행합니다. 한 번은 스킬을 사용하여, 한 번은 스킬 없이 (또는 기존 스킬을 개선하는 경우 이전 버전으로).

워크스페이스 구조

결과는 스킬 디렉토리와 형제 관계인 <skill-name>-workspace/에 저장됩니다:

api-tester-workspace/
├── iteration-1/
│   ├── eval-0-auth-failure/
│   │   ├── with_skill/
│   │   │   ├── outputs/
│   │   │   └── timing.json
│   │   ├── without_skill/
│   │   │   ├── outputs/
│   │   │   └── timing.json
│   │   └── eval_metadata.json
│   ├── eval-1-pagination/
│   │   └── ...
│   ├── benchmark.json
│   └── benchmark.md
├── iteration-2/
└── feedback.json

병렬 실행 시작

각 테스트 케이스에 대해 동일한 턴에서 두 개의 서브 에이전트를 생성합니다:

스킬 사용 실행:

이 작업을 실행합니다:
- 스킬 경로: /path/to/api-tester
- 작업: api.example.com의 /users 엔드포인트를 테스트합니다
- 입력 파일: 없음
- 출력 저장 위치: api-tester-workspace/iteration-1/eval-0/with_skill/outputs/

기준선 실행:

이 작업을 실행합니다:
- 스킬 경로: (없음)
- 작업: api.example.com의 /users 엔드포인트를 테스트합니다
- 입력 파일: 없음
- 출력 저장 위치: api-tester-workspace/iteration-1/eval-0/without_skill/outputs/

타이밍 데이터 캡처

각 서브 에이전트가 완료되면 total_tokens 및 duration_ms를 받습니다. 즉시 timing.json에 저장합니다:

{
  "total_tokens": 84852,
  "duration_ms": 23332,
  "total_duration_seconds": 23.3
}

이 데이터는 작업 알림을 통해서만 제공됩니다. 도착하는 대로 각 데이터를 처리합니다.

5단계: 실행 완료 중 어설션 초안 작성

실행이 완료되기를 기다리지 마세요. 그 시간을 생산적으로 사용하여 정량적 어설션을 작성하세요.

좋은 어설션이란

좋은 어설션은 다음과 같습니다:

객관적으로 검증 가능 - 통과/실패가 명확함
설명적으로 명명됨 - 무엇을 확인하는지 명확함
재사용 가능 - 여러 반복에 걸쳐 작동함

API 테스트 스킬에 대한 예시 어설션:

{
  "assertions": [
    {
      "name": "includes_auth_failure_test",
      "description": "테스트 보고서에 최소 하나의 인증 실패 테스트 케이스가 포함되어 있습니다",
      "type": "contains",
      "value": "401"
    },
    {
      "name": "includes_success_test",
      "description": "테스트 보고서에 최소 하나의 성공적인 요청 테스트가 포함되어 있습니다",
      "type": "contains",
      "value": "200"
    },
    {
      "name": "includes_curl_commands",
      "description": "각 테스트 케이스에는 실행 가능한 curl 명령이 포함되어 있습니다",
      "type": "regex",
      "value": "curl -"
    },
    {
      "name": "includes_response_validation",
      "description": "보고서가 스키마에 대해 응답 구조를 검증합니다",
      "type": "contains",
      "value": "schema"
    }
  ]
}

초안이 작성되면 eval_metadata.json 및 evals/evals.json을 어설션으로 업데이트합니다.

6단계: 채점 및 집계

모든 실행이 완료되면:

각 실행 채점

agents/grader.md를 읽고 출력에 대해 각 어설션을 평가하는 채점 서브 에이전트를 생성합니다. 결과를 각 실행 디렉토리의 grading.json에 저장합니다:

{
  "eval_id": 0,
  "grading": [
    {
      "text": "includes_auth_failure_test",
      "passed": true,
      "evidence": "테스트 케이스 3에서 401 상태 코드를 발견했습니다"
    },
    {
      "text": "includes_curl_commands",
      "passed": true,
      "evidence": "테스트 케이스 1에서 'curl -X POST'를 발견했습니다"
    }
  ]
}

중요: grading.json의 기대값 배열은 text, passed, evidence 필드 이름을 사용해야 합니다. 뷰어는 이 정확한 이름에 의존합니다.

벤치마크로 집계

skill-creator 디렉토리에서 집계 스크립트를 실행합니다:

python -m scripts.aggregate_benchmark api-tester-workspace/iteration-1 --skill-name api-tester

이렇게 하면 각 구성에 대한 pass_rate, 시간, 토큰이 포함된 benchmark.json 및 benchmark.md가 생성되며, 평균 ± 표준편차 및 델타가 포함됩니다.

분석가 검토 수행

벤치마크 데이터를 읽고 패턴을 파악합니다:

비판별 어설션 - 스킬과 관계없이 항상 통과함 (유용하지 않음)
높은 분산 평가 - 불안정할 수 있으므로 조사가 필요함
시간/토큰 절충 - 스킬이 합리적인 비용으로 품질을 향상시키는가?

자세한 지침은 agents/analyzer.md를 참조하세요.

7단계: 평가 뷰어 실행

평가 뷰어는 브라우저 인터페이스에서 정성적 출력과 정량적 지표를 모두 보여줍니다.

뷰어 생성

nohup python /path/to/skill-creator/eval-viewer/generate_review.py \
  api-tester-workspace/iteration-1 \
  --skill-name "api-tester" \
  --benchmark api-tester-workspace/iteration-1/benchmark.json \
  > /dev/null 2>&1 &
VIEWER_PID=$!

2단계 이상인 경우 --previous-workspace도 전달합니다:

--previous-workspace api-tester-workspace/iteration-1

사용자가 보는 것

출력 탭은 한 번에 하나의 테스트 케이스를 보여줍니다:

프롬프트 - 주어진 작업
출력 - 생성된 파일, 인라인 렌더링
이전 출력 (2단계 이상) - 이전 반복의 출력이 포함된 접힌 섹션
공식 등급 - 접힌 어설션 통과/실패
피드백 - 입력하는 대로 자동 저장되는 텍스트 상자
이전 피드백 (2단계 이상) - 이전 반복의 댓글

벤치마크 탭은 다음을 보여줍니다:

각 구성에 대한 통과율
타이밍 비교
토큰 사용량
평가별 세부 분석
분석가 관찰

사용자에게 말합니다: "브라우저에 결과를 열었습니다. '출력' 탭에서는 각 테스트 케이스를 클릭하고 피드백을 남길 수 있으며, '벤치마크' 탭에서는 정량적 비교를 보여줍니다. 완료되면 여기로 돌아와 알려주세요."

협업 / 헤드리스 환경

webbrowser.open()을 사용할 수 없는 경우 --static을 사용하여 독립형 HTML 파일을 작성합니다:

--static /path/to/output/review.html

사용자가 "모든 검토 제출"을 클릭하면 피드백이 feedback.json으로 다운로드됩니다.

8단계: 피드백 읽기 및 반복

사용자가 완료하면 feedback.json을 읽습니다:

{
  "reviews": [
    {
      "run_id": "eval-0-with_skill",
      "feedback": "차트에 축 레이블이 없습니다",
      "timestamp": "2026-03-23T10:30:00Z"
    },
    {
      "run_id": "eval-1-with_skill",
      "feedback": "",
      "timestamp": "2026-03-23T10:31:00Z"
    },
    {
      "run_id": "eval-2-with_skill",
      "feedback": "완벽해요, 아주 좋습니다",
      "timestamp": "2026-03-23T10:32:00Z"
    }
  ],
  "status": "complete"
}

빈 피드백은 사용자가 괜찮다고 생각했다는 의미입니다. 특정 불만이 있는 테스트 케이스에 개선 사항을 집중합니다.

개선 사항에 대한 생각

피드백으로부터 일반화: 수많은 프롬프트에서 수천 번 사용되는 스킬을 만들고 있습니다. 특정 테스트 케이스에 과적합하지 마세요. 고질적인 문제가 있다면 제한적인 MUST 문구 대신 다른 은유나 패턴을 시도해 보세요.

프롬프트를 간결하게 유지: 불필요한 부분을 제거하세요. 최종 출력뿐만 아니라 스크립트도 읽으세요. 스킬이 모델이 비생산적인 단계에서 시간을 낭비하게 만든다면 해당 부분을 제거하세요.

이유 설명: LLM은 뛰어난 마음의 이론을 가지고 있습니다. 좋은 지시를 받으면 기계적인 지시 이상으로 수행합니다. 각 요구 사항이 왜 중요한지 설명하세요. 모든 문구에 항상(ALWAYS) 또는 절대(NEVER)를 대문자로 작성하고 있다면, 대신 이유를 재구성하고 설명하세요.

반복되는 작업 찾기: 모든 테스트 케이스가 독립적으로 유사한 도우미 스크립트를 작성했습니까? 그것은 스킬이 해당 스크립트를 번들로 묶어야 한다는 신호입니다. 한 번 작성하고 scripts/에 넣은 다음 스킬에 사용하도록 지시하세요.

반복 루프

스킬에 개선 사항 적용
기준선 실행과 함께 모든 테스트 케이스를 iteration-<N+1>/로 다시 실행
이전 반복을 가리키는 --previous-workspace로 뷰어 실행
사용자 검토 대기
새로운 피드백을 읽고 다시 개선, 반복

다음까지 계속합니다:

사용자가 만족한다고 말할 때까지
모든 피드백이 비어 있을 때까지 (모든 것이 좋아 보일 때까지)
의미 있는 진전을 이루지 못할 때까지

완료되면 뷰어를 종료합니다:

kill $VIEWER_PID 2>/dev/null

9단계: 스킬 설명 최적화

SKILL.md frontmatter의 설명 필드는 주요 트리거링 메커니즘입니다. 스킬을 생성하거나 개선한 후에는 트리거 정확도를 높이기 위해 최적화합니다.

트리거 평가 쿼리 생성

트리거되어야 하는 것과 트리거되지 않아야 하는 것을 혼합하여 20개의 평가 쿼리를 생성합니다:

[
  {
    "query": "음, 상사가 방금 이 xlsx 파일을 보냈는데 (내 다운로드 폴더에 'Q4 sales final FINAL v2.xlsx' 같은 이름으로 있어요) 수익 마진을 백분율로 보여주는 열을 추가해달래요. 매출은 C열에 있고 비용은 D열에 있는 것 같아요",
    "should_trigger": true
  },
  {
    "query": "이 CSV에서 피벗 테이블을 만들어서 팀에 이메일로 보내야 합니다",
    "should_trigger": false
  }
]

트리거되어야 하는 쿼리 (8-10개):

동일한 의도의 다른 표현
공식 및 비공식 언어
사용자가 스킬을 명시적으로 언급하지 않지만 분명히 필요한 경우
엣지 케이스 및 흔치 않은 사용 사례

트리거되지 않아야 하는 쿼리 (8-10개):

키워드를 공유하지만 다른 것이 필요한 거의 일치하는 사례
다른 도구가 더 적합한 인접 도메인
순진한 키워드 매칭이 잘못 트리거될 수 있는 모호한 문구

나쁜 부정 테스트: PDF 스킬에 대한 부정 테스트로 "피보나치 함수를 작성해라"는 너무 쉽습니다. 부정 케이스는 정말 까다로워야 합니다.

사용자와 함께 검토

HTML 템플릿을 사용하여 평가 세트를 제시합니다:

assets/eval_review.html 읽기
평가 데이터, 스킬 이름, 설명으로 자리 표시자 바꾸기
임시 파일에 작성하고 열기: open /tmp/eval_review_api-tester.html
사용자는 쿼리를 편집하고, 트리거 여부를 전환하고, 항목을 추가/제거할 수 있습니다
사용자는 "평가 세트 내보내기"를 클릭합니다
파일이 ~/Downloads/eval_set.json으로 다운로드됩니다

이 단계가 중요합니다. 나쁜 평가 쿼리는 나쁜 설명으로 이어집니다.

최적화 루프 실행

python -m scripts.run_loop \
  --eval-set /path/to/trigger-eval.json \
  --skill-path /path/to/api-tester \
  --model claude-sonnet-4-6 \
  --max-iterations 5 \
  --verbose

현재 세션을 구동하는 모델 ID를 사용하여 트리거링 테스트가 사용자의 경험과 일치하도록 합니다.

스크립트는 다음을 수행합니다:

평가 세트를 60% 학습, 40% 보류 테스트로 분할
현재 설명 평가 (신뢰성을 위해 각 3회 실행)
실패를 기반으로 개선을 제안하도록 Claude 호출
학습 및 테스트에 대해 다시 평가
최대 5회 반복
테스트 점수(과적합 방지를 위해 학습 점수 아님)로 선택된 best_description 반환

결과 적용

JSON 출력에서 best_description을 가져와 스킬의 SKILL.md frontmatter를 업데이트합니다. 점수와 함께 전후를 사용자에게 보여줍니다.

전:

description: REST API를 체계적으로 테스트하는 방법

후:

description: REST API를 체계적으로 테스트하는 방법. 사용자가 API 테스트, 엔드포인트, REST, GraphQL을 언급하거나 API 응답을 검증하고자 할 때 사용합니다. '테스트'를 명시적으로 언급하지 않더라도 테스트가 관련될 때마다 이 스킬을 제안해야 합니다.

10단계: 패키징 및 배포

스킬이 완료되면 배포를 위해 패키징합니다:

python -m scripts.package_skill /path/to/api-tester

이렇게 하면 사용자가 설치할 수 있는 .skill 파일이 생성됩니다. 사용자에게 결과 파일 경로를 안내합니다.

설치

사용자는 .skill 파일을 스킬 디렉토리에 넣거나 Claude 코드 스킬 설치 명령을 사용하여 스킬을 설치합니다.

일반적인 스킬 생성 오류

오류 1: 모호한 설명

나쁜 예시:

description: API 작업을 위한 스킬

좋은 예시:

description: REST API를 체계적으로 테스트하는 방법. 사용자가 API 테스트, 엔드포인트, REST, GraphQL을 언급하거나 API 응답을 검증하고자 할 때 사용합니다. '테스트'를 명시적으로 언급하지 않더라도 테스트가 관련될 때마다 이 스킬을 제안해야 합니다.

오류 2: 지나치게 제한적인 지시사항

나쁜 예시:

항상 이 정확한 형식을 사용하십시오. 절대로 벗어나지 마십시오. 이 섹션을 반드시 포함해야 합니다.

좋은 예시:

이 형식을 사용하면 이해 관계자들이 필요한 정보를 신속하게 찾을 수 있습니다. 청중의 요구 사항이 다를 경우 그에 따라 구조를 조정하십시오.

오류 3: 테스트 케이스 생략

테스트 케이스는 사용자가 문제를 만나기 전에 문제를 찾아냅니다. 주관적인 스킬이라도 2-3가지 예시를 실행하여 출력 품질을 확인하세요.

오류 4: 타이밍 데이터 무시

10배 더 오래 걸리는 스킬은 지속 가능하지 않습니다. 타이밍 데이터를 캡처하고 품질과 함께 효율성을 최적화하세요.

오류 5: 반복되는 스크립트 번들링 안 함

모든 테스트 실행이 독립적으로 generate_report.py를 작성한다면, 그것을 스킬에 번들로 묶으세요. 시간을 절약하고 일관성을 보장합니다.

실제 스킬 예시

MCP 빌더 스킬

Anthropic이 MCP(Model Context Protocol) 서버 구축을 위해 만들었습니다.

주요 기능:

Python 및 Node.js 템플릿
MCP 서버를 위한 평가 프레임워크
모범 사례 참조 문서

구조:

mcp-builder/
├── SKILL.md
├── reference/
│   ├── mcp_best_practices.md
│   ├── python_mcp_server.md
│   └── node_mcp_server.md
└── evaluation/
    └── evaluation.md

Docx 스킬

프로그래밍 방식으로 Word 문서를 생성합니다.

주요 기능:

번들로 제공되는 python-docx 스크립트
일반 문서용 템플릿 시스템
일관된 서식을 위한 스타일링 가이드

워크플로:

문서 요구 사항 이해
템플릿 선택 또는 생성
python-docx 스크립트를 통해 생성
출력 구조 검증

프론트엔드 디자인 스킬

현대적인 패턴으로 웹 인터페이스를 구축합니다.

주요 기능:

컴포넌트 라이브러리
Tailwind CSS 패턴
접근성 검사

점진적 공개: SKILL.md의 핵심 워크플로, references/의 컴포넌트 문서.

Apidog로 스킬 테스트

API 관련 스킬을 구축하는 경우 Apidog가 워크플로에 자연스럽게 통합됩니다.

예시: API 테스트 스킬 통합

## API 테스트 실행

체계적인 테스트를 위해 Apidog를 사용합니다:

1. OpenAPI 사양을 Apidog로 가져오기
2. 사양에서 테스트 케이스 생성
3. 테스트 실행 및 결과를 JSON으로 내보내기
4. 예상 스키마에 대해 응답 검증

사용자 정의 어설션의 경우 Apidog의 스크립팅 기능을 사용합니다.

Apidog 스크립트 번들링

api-tester/
├── SKILL.md
└── scripts/
    ├── run-apidog-tests.py
    └── generate-report.py

이렇게 하면 모든 향후 호출에서 바퀴를 재발명하는 것을 방지할 수 있습니다.

결론

Claude 코드 스킬은 특정 워크플로를 위해 Claude의 기능을 확장합니다. 스킬 생성기 시스템은 체계적인 프로세스를 제공합니다:

의도 포착 - 스킬이 무엇을 해야 하는지 정의
SKILL.md 초안 작성 - 예시와 함께 명확한 지시사항 작성
테스트 케이스 생성 - 사용자가 실제로 만들 현실적인 프롬프트
평가 실행 - 스킬 사용 여부에 따른 병렬 실행
결과 검토 - 정성적 피드백 + 정량적 벤치마크
반복 - 발견 사항을 기반으로 개선
설명 최적화 - 트리거 정확도 최대화
패키징 - .skill 파일로 배포

버튼

FAQ

스킬을 만드는 데 얼마나 걸리나요?

간단한 스킬은 15-30분이 소요됩니다. 여러 참조 파일과 번들 스크립트가 있는 복잡한 스킬은 평가 반복을 포함하여 2-3시간이 소요될 수 있습니다.

모든 스킬에 대해 테스트 케이스를 작성해야 하나요?

아니요. 객관적으로 검증 가능한 출력(코드 생성, 파일 변환, 데이터 추출)이 있는 스킬은 테스트 케이스의 이점을 얻습니다. 주관적인 출력(글쓰기 스타일, 디자인 품질)이 있는 스킬은 정성적으로 평가하는 것이 좋습니다.

스킬이 안정적으로 트리거되지 않으면 어떻게 해야 하나요?

설명 필드를 최적화하세요. 특정 트리거 문구와 컨텍스트를 포함하세요. 약간 "강력하게" 만들어서 스킬을 언제 사용해야 하는지 명시적으로 언급하세요. 20개의 평가 쿼리로 설명 최적화 루프를 실행하세요.

팀과 스킬을 어떻게 공유하나요?

python -m scripts.package_skill <path>를 사용하여 스킬을 패키징한 다음 .skill 파일을 배포하세요. 팀 구성원은 해당 파일을 스킬 디렉토리에 배치합니다.

스킬이 외부 API를 호출할 수 있나요?

예. API 호출을 하는 스크립트를 번들로 묶으세요. 스킬 지시사항은 Claude에게 언제 어떻게 사용할지 알려줍니다. API 키는 스킬 자체에 저장하지 말고 환경 변수에 저장하세요.

스킬의 파일 크기 제한은 무엇인가요?

정해진 제한은 없지만 SKILL.md를 500줄 이하로 유지하세요. 자세한 참조는 별도의 파일로 이동하세요. 스크립트와 자산은 필요할 때 로드되므로 줄 수 제한에 포함되지 않습니다.

기존 스킬은 어떻게 업데이트하나요?

설치된 스킬을 쓰기 가능한 위치로 복사하고 거기서 편집한 다음 다시 패키징하세요. 원래 이름을 유지하세요. 별개의 변형을 만들지 않는 한 버전 접미사를 추가하지 마세요.