스킬로 절차를 담기

이 장에서 배우는 것 스킬이 지시문·에이전트와 무엇이 다른지, 어디에 놓이는지, 그리고 언제 만들지.

세 가지 재사용 단위

지금까지 "반복을 줄이는 법"이 세 번 나왔습니다. 헷갈리기 쉬워서 정리합니다.

스킬의 차이는 파일로 존재한다는 점입니다.

폴더가 곧 상태입니다

스킬은 데이터베이스에 저장되지 않습니다. 폴더를 훑어서 발견합니다.

이 설계의 결과가 중요합니다.

첫 줄이 핵심입니다. 지시문을 개인 메모에 두면 그 사람 것이지만, 스킬은 저장소에 들어가 팀의 자산이 됩니다.

SKILL.md 하나면 됩니다

description이 가장 중요합니다

모델은 이 한 줄을 읽고 이 스킬을 쓸지 판단합니다. MCP 도구 설명과 완전히 같은 원리입니다.

"언제 쓰는지"를 반드시 넣으세요. 그게 없으면 안 불립니다.

스킬 탭입니다. 이 폴더와 그 외를 나눠 보여주고, 설치 경로도 함께 적혀 있습니다 — 편집할 수 있는 것은 이 폴더뿐입니다.

네 개의 자리

스킬은 네 군데에서 발견됩니다. 읽기는 넷 다, 쓰기는 하나뿐입니다.

화면에서 설치·삭제하면 <작업 폴더>/.claude/skills에만 손댑니다. 나머지 셋은 이 기계·관리자·플러그인의 것이라 목록에만 나오고 건드리지 않습니다.

그래서 스킬을 만들 때는 project 자리에 만듭니다. 그러면 그 폴더의 저장소에 들어가 팀이 함께 씁니다.

언제 만드나

graph TD
  A["같은 일을 반복한다"] --> B{"매번 지시문이<br/>거의 같은가?"}
  B -->|"아니오"| C["그냥 대화로"]
  B -->|"예"| D{"딸린 자료가<br/>있는가?"}
  D -->|"없음"| E["에이전트 또는 템플릿"]
  D -->|"있음"| F["스킬"]
  B -->|"예"| G{"팀이 함께 쓰나?"}
  G -->|"예"| F

스킬이 맞는 신호 셋입니다.

세 번째가 특히 스킬다운 경우입니다. "배포 점검"은 프로젝트마다 확인할 것이 다른데, 스킬이 작업 폴더 안에 있으니 각 프로젝트가 자기 버전을 가집니다.

만들지 말아야 할 때

스킬은 절차이지 도구가 아닙니다. 무언가를 조회하거나 실행해야 하면 그건 도구 쪽입니다.

실무 요령

하지 말 것을 적으세요

범위는 하지 말 것으로 적는 게 효과적이라는 원칙이 스킬에서도 그대로입니다. 특히 스킬은 여러 사람이 쓰므로 경계가 더 중요합니다.

자료를 함께 두세요

예시 하나가 설명 열 줄보다 정확합니다.

폴더 이름과 name을 맞추세요

프론트매터의 name이 폴더 이름과 달라도 동작은 합니다. 다만 파일을 다룰 때는 폴더 이름이 기준이라, 다르면 지우거나 옮길 때 헷갈립니다. 맞춰두세요.

점검 목록을 남기세요

분기에 한 번쯤:

세 번째가 스킬 특유의 문제입니다. 절차가 바뀌었는데 스킬이 그대로면 틀린 절차를 자신 있게 반복합니다.

확인

1. 스킬이 지시문 템플릿과 다른 결정적인 점은?

2. description에 반드시 넣어야 하는 것은?

3. 네 개의 자리 중 편집할 수 있는 곳은 어디이고 왜입니까?

문서를 자료로 바꾸는 법을 봅니다 → 문서를 자료로 바꾸기