elle510/make-skill

Skill: make-skill

발동 조건

사용자가 다음을 요청할 때 이 스킬을 사용한다:

• "스킬 만들어줘", "skill 작성해줘", "새 스킬 추가해줘"
• "스킬 개선해줘", "스킬 보완해줘", "기존 스킬 업데이트해줘"
• "스킬 검토해줘", "스킬 가이드대로 됐는지 확인해줘", "스킬 리뷰해줘"
• /make-skill

이 스킬의 목적

Claude Code 스킬을 올바른 구조와 원칙에 따라 만든다.

핵심 원칙: 스킬은 파일이 아니라 폴더다. 단일 SKILL.md 파일 대신, Claude가 필요할 때 꺼내 읽는 재료와 도구를 함께 제공한다.

참조 파일 (필요할 때 읽을 것)

| 파일 | 내용 | | -------------------------------- | ---------------------------------------------------------------- | | references/9-patterns.md | 스킬 유형 9가지 체크리스트 — 어떤 유형의 스킬인지 먼저 판단할 때 | | references/4-principles.md | 스킬 작성 4대 원칙 — SKILL.md 초안 작성 전 반드시 확인 | | references/examples.md | 좋은/나쁜 사례 모음 — Description과 Gotchas 작성 시 참고 | | assets/skill-template/SKILL.md | 보일러플레이트 — 새 스킬 초안 시작점 | | scripts/validate-skill.sh | 검증 스크립트 — 완성 후 실행하여 누락 항목 확인 |

모드 선택

요청 의도에 따라 두 가지 모드 중 하나로 실행한다.

| 모드 | 발동 키워드 | 아웃풋 | | ------------------ | ------------------------------------------ | -------------------------------------- | | 생성/수정 모드 | 만들어줘, 추가해줘, 개선해줘, 업데이트해줘 | 스킬 파일 생성 또는 수정 | | 리뷰 모드 | 검토해줘, 확인해줘, 리뷰해줘 | 읽기 전용 감사 리포트 (파일 수정 없음) |

---

생성/수정 모드 절차

1단계: 스킬 유형 판단

references/9-patterns.md를 읽고 어떤 유형인지 파악한다. 하나의 유형에 깔끔하게 들어맞지 않으면 사용자에게 확인한다.

2단계: 스킬 폴더 구조 설계

스킬 이름을 결정하고 폴더 구조를 설계한다.

기본 구조:

.claude/skills/{skill-name}/
├── SKILL.md              # 진입점 — 개요와 파일 목록만 (점진적 공개)
├── references/           # API 문서, 규칙, 상세 설명
├── assets/               # 출력 템플릿, 보일러플레이트
└── scripts/              # 검증/헬퍼 스크립트 (선택)

단순한 스킬(절차만 있고 참조 없음)은 단일 파일도 허용. 단, 내용이 길어지면 분리한다.

3단계: SKILL.md 초안 작성

assets/skill-template/SKILL.md를 기반으로 작성한다. references/4-principles.md의 원칙 4가지를 모두 지킨다.

반드시 포함할 섹션:

• 발동 조건 (trigger — 요약이 아닌 "언제 켜야 하는지")
• 절차 또는 규칙
• Gotchas (Claude가 실수하기 쉬운 함정)

4단계: 상세 내용 분리 (점진적 공개)

SKILL.md에 API 문서, 긴 예시, 템플릿 등이 들어가면 references/나 assets/로 분리한다. SKILL.md에는 "필요하면 X 파일을 읽어라"는 포인터만 남긴다.

5단계: settings.json 등록

스킬을 만든 후에는 /update-config 스킬로 settings.json에 등록해야 한다. 등록하지 않으면 /skill-name으로 호출할 수 없다.

6단계: 검증

bash .claude/skills/make-skill/scripts/validate-skill.sh .claude/skills/{skill-name}

결과에서 누락된 항목을 보완한다.

리뷰 모드 절차

대상 스킬 경로를 받아 읽기 전용으로 감사한다. 파일을 수정하지 않는다.

references/4-principles.md와 references/examples.md를 참고하여 아래 항목을 순서대로 점검한다.

1. 단일 유형 원칙 (references/9-patterns.md 참고)

• 이 스킬은 9가지 유형 중 하나에 깔끔하게 들어맞는가?
• 두 유형에 걸쳐 있으면 → 분리 권고

2. 발동 조건 품질

• 발동 조건이 "언제 켜야 하는가"를 명확히 서술하는가?
• "이 스킬은 X를 한다" 형식이면 → 트리거 조건 형식으로 재작성 권고

3. 뻔한 말 제거 원칙

• Claude가 이미 아는 범용 지식이 포함되어 있는가?
• 이 팀/프로젝트만 아는 규칙이 있는가?

4. Gotchas 섹션 품질

• Gotchas 섹션이 존재하는가?
• 내용이 범용적("오류 시 사용자에게 알린다")이 아닌 이 스킬에서만 발생하는 함정인가?

5. 점진적 공개 원칙

• SKILL.md가 100줄을 넘는가? → 분리 권고
• 상세 내용(API 문서, 긴 예시, 템플릿)이 SKILL.md에 직접 포함되어 있는가?

리뷰 결과 출력 형식

## 스킬 리뷰 결과: {skill-name}

### 통과
- ...

### 개선 권고
1. [항목] 문제: ... → 권고: ...

### 총평
N개 항목 중 N개 통과. 수정이 필요한 경우 "개선해줘"로 요청하세요.

---

Gotchas

• Description 필드 실수: "이 스킬은 X를 한다"처럼 요약 쓰지 말 것. "사용자가 X를 하려 할 때" 형식의 트리거 조건으로 써야 한다.
• 모든 것을 SKILL.md에 넣지 말 것: 컨텍스트 낭비. 상세 내용은 references/로 분리하고 포인터만 남긴다.
• Gotchas 섹션 누락: 처음엔 짧아도 괜찮다. 나중에 Claude가 실수할 때마다 추가한다.
• settings.json 등록 누락: 파일만 만들어선 /skill-name으로 호출 안 됨.
• 기존 스킬 덮어쓰기: 수정 전 반드시 기존 내용을 읽고 시작한다.