서론: CLAUDE.md의 비대화와 커맨드 위치 문제로 고민하고 계신가요

"CLAUDE.md에 규칙을 계속 추가한 결과, 매번 주고받는 대화에서 컨텍스트 (Context)를 압박하고 있다"

"2026년 1월에 커스텀 슬래시 커맨드 (Slash Command)가 Skills로 통합되었다고 들었는데, 기존의 .claude/commands/는 어떻게 해야 할지 모르겠다"

"편리한 절차서를 개인적으로 만들었지만, 팀에 배포하는 방법과 통제하는 방식을 정하지 못했다"

Claude Code를 몇 달간 사용한 팀은 대개 이 세 가지 과제에 도달합니다. 결론부터 말씀드리면, 이 세 가지는 모두 Agent Skills (이하 Skills)로 해결할 수 있습니다. Skills는 작업별 절차서를 파일 형태로 Claude Code에 가지고 있다가, 필요할 때만 읽어들이는 공식 기능입니다. CLAUDE.md는 작성된 내용의 전문이 매번 읽히지만, Skills는 컨텍스트 (Claude가 한 번에 읽을 수 있는 정보의 범위)를 거의 사용하지 않습니다. 따라서 절차서를 수십 개라도 가질 수 있습니다.

본 기사에서는 슬래시 커맨드 통합 이후의 "새로운 상식"을 정리한 후, 복사해서 바로 사용할 수 있는 자작 스킬 레시피와 팀 배포 및 통제까지 해설합니다. 사양 설명은 모두 Anthropic 공식 문서 (Claude Code Skills 레퍼런스)에, 동작 설명은 모두 실기 검증에 근거를 두고 있습니다 (검증 환경은 기사 말미에 기재).

참고로, Claude Code 자체를 이제 막 도입하려는 단계에 계신 분들은 먼저 전체적인 모습부터 파악하시면 본 기사를 읽어나가기 수월합니다. Claude Code의 도입부터 실무 활용까지 체계적으로 파악하고 싶은 분은 이쪽도 참고해 주세요.

이 기사를 통해 얻을 수 있는 것:

• Skills의 구조 (3단계 읽기)와 CLAUDE.md, Hooks, 서브 에이전트 (Sub-agent)와의 구분 사용
• 슬래시 커맨드 통합으로 변한 점 및 기존 .claude/commands/의 취급
• 커밋 메시지 규약, 문체 체크, 읽기 전용 감사 등 바로 사용할 수 있는 스킬 레시피
• 서브 에이전트 분리 실행 (context: fork), 발동 범위 한정 (paths) 등 2026년에 추가된 신기능의 활용법
• Git 공유 및 조직 설정을 통한 팀 배포와 외부 제작 스킬 도입 시의 감사 관점

1. 기초 지식: Agent Skills란 무엇인가

1-1. CLAUDE.md의 한계와 "단계적 읽기"

Skills의 실체는 SKILL.md라는 이름의 Markdown 파일을 넣은 폴더입니다. 여기에 절차서를 작성해 두면 Claude가 필요하다고 판단했을 때만 읽어들입니다. 2025년 10월 16일에 claude.ai, Claude Code, Claude API 세 가지에서 동시에 출시되었으며, 2025년 12월에는 오픈 표준 (agentskills.io)이 되었습니다. 오픈 표준이란 어떤 회사의 도구에서도 사용할 수 있는 공통된 작성 방식을 말합니다. 현재는 VS Code나 Codex CLI 등 Anthropic 이외의 도구도 동일한 SKILL.md를 읽을 수 있으므로, 한 번 작성한 절차서는 오래 사용할 수 있는 자산이 됩니다.

CLAUDE.md와의 가장 큰 차이점은 컨텍스트 (Context)의 사용 방식입니다. Skills는 필요해지기 전까지 상세 내용을 읽지 않는 단계적 읽기 (공식 문서에서는 progressive disclosure)라는 3단계 설계로 되어 있습니다.

보충: 토큰 기준은 공식 문서(Agent Skills Overview)의 기재 내용을 바탕으로 합니다. 토큰은 Claude가 읽고 쓰는 문장량의 단위입니다(일본어의 경우 대략 1~2글자당 1토큰). 예를 들어, 절차서 10개를 합쳐 총 2만 토큰 상당을 CLAUDE.md에 직접 작성하면, 매번 2만 토큰이 읽힙니다. Skills로 만들면 평소에 읽히는 것은 개당 약 100토큰(이름과 설명문)뿐이며, 합계로도 약 1,000토큰 정도로 끝나는 계산입니다.

CLAUDE.md 작성법 자체를 다시 검토하고 싶은 분은 이쪽도 참고해 주세요.

1-2. 슬래시 명령어 통합의 새로운 상식 (2026년 1월~)

Claude Code에서는 오랫동안 .claude/commands/*.md에 커스텀 슬래시 명령어(Slash Command)를 두는 방식이 사용되어 왔으나, 2026년 1월 말(v2.1.3)에 커스텀 슬래시 명령어는 Skills로 통합되었습니다. 파악해야 할 사실은 4가지입니다.

• 기존 방식의 마이그레이션은 필수 사항이 아닙니다. .claude/commands/는 지금도 작동합니다.
• .claude/commands/review.md와 .claude/skills/review/SKILL.md는 둘 다 동일한 /review 명령어를 만듭니다. 동일한 이름으로 공존할 경우 Skills 측이 우선됩니다.
• 기존 commands도 「자동 발동」하게 되었습니다. 통합 전에는 기본적으로 직접 /이름을 입력했을 때만 작동하는 것이었습니다. 통합 후에는 스킬의 설명문인 description(설명문이 없는 파일은 본문 첫 줄이 설명문으로 취급됨)이 대화 내용과 일치하면, 요청하지 않아도 Claude가 자동으로 실행합니다.
• 보조 파일 동봉, 발동 제어, 서브 에이전트(Sub-agent) 연동 등의 신기능은 Skills 측에만 추가됩니다. 새로 만드는 것은 Skills로 작성해 주세요.

3번이 실무상 가장 주의해야 할 점입니다. 배포나 파일 생성처럼 멋대로 실행되면 곤란한 절차에는 프론트매터(frontmatter, 파일 도입부를 ---로 감싸서 작성하는 스킬 설정란)에 disable-model-invocation: true를 붙여주세요. 이렇게 하면 직접 호출했을 때만 작동하는 상태로 되돌릴 수 있습니다(작성법은 2장에서 설명합니다).

참고로, Web 버전 Claude(claude.ai)에도 Word나 Excel을 다루는 「Skills」가 있습니다. 사양은 동일한 표준을 기반으로 하지만, 플랫폼 간에 스킬은 동기화되지 않습니다. claude.ai 측의 활용법은 이 별도의 기사에서 소개하고 있으므로, 본 기사는 Claude Code에서 직접 만드는 스킬에 집중합니다.

1-3. CLAUDE.md · Hooks · 서브 에이전트와의 구분 사용

Skills의 역할은 「필요할 때만 읽는 절차서」입니다. 유사한 기능이 다른 곳에도 있으므로, 구분 사용법을 정리합니다. 서브 에이전트(Sub-agent)는 메인 대화와 별개로 실행되는 또 다른 Claude를 의미합니다.

보충: Skills는 어디까지나 LLM에 대한 지시이며, 확실한 강제는 불가능합니다. 확실히 중단시키고 싶은 처리는 Hooks와 조합합니다(3-5의 레시피에서 실연합니다). Claude Code의 Hooks를 통한 처리 제어에 대해서는 이쪽도 참고해 주세요.

2. 구현 단계: 첫 번째 스킬을 10분 만에 만들기

스킬을 만드는 방법은 「파일을 배치한다 → 발동을 설계한다 → 보조 파일을 추가한다」의 3단계입니다. 예시로 커밋 메시지(Commit Message) 규약 스킬을 만들어 보겠습니다.

어떤 스킬인지 먼저 설명하겠습니다. 커밋 전에 /commit-msg를 입력하면, Claude가 스테이징된 변경 사항(git add한 변경 사항)의 내용을 읽고, 팀의 서식 규약(첫 줄은 종류: 요약, 본문에는 변경 이유를 1~2줄)에 따른 커밋 메시지 초안을 제안합니다. 사람은 돌아온 초안을 확인하고 그대로 커밋에 사용하기만 하면 됩니다. 커밋 메시지 서식은 사람마다 달라지기 쉽고, 규약을 매번 떠올리는 것도 번거롭기 때문에 절차서로 만들어 둘 가치가 있습니다.

먼저 2-1에서 이 스킬을 완성하겠습니다. 이어지는 2-2와 2-3에서는 나머지 2단계(발동 설계 · 보조 파일 동봉)의 개념을 설명합니다.

2-1. 최소한의 SKILL.md 배치

프로젝트 직하에 다음 폴더와 파일을 만드는 것만으로 /commit-msg 명령어를 사용할 수 있게 됩니다.

.claude/
└── skills/
└── commit-msg/
...

---
name: commit-msg # 목록에 표시되는 표시 이름 (명령어 이름은 폴더명으로 결정됨)
description: 스테이징된 변경 사항으로부터 커밋 메시지 초안을 작성함 # 스킬의 설명문 (자동 발동 스킬에서는 발동 판정에 사용됨)
...

파일 구조는 2부 구성입니다. 서두의 ---로 둘러싸인 부분이 frontmatter(스킬의 동작 방식을 결정하는 설정란)이며, 그 아래는 스킬 발동 시 Claude에게 전달되는 지시 본문입니다. frontmatter의 각 필드 의미는 코드 내의 주석과 같으며, 이후의 레시피도 모두 이 구조로 작성합니다.

이 레시피에는 스킬의 기본 요소 4가지가 들어 있습니다.

• !command를 통한 명령어 출력 임베딩: 본문이 Claude에게 전송되기 직전에 셸 명령어가 실행되며, 작성한 위치가 실행 결과로 대체됩니다. 차이점(diff)이나 브랜치 이름 등 '현재 상태'를 절차서에 자동으로 삽입할 수 있습니다.
• $ARGUMENTS: /commit-msg 티켓 번호를 입력해와 같이 입력했을 때, 명령어 이름 뒤에 쓴 문자(즉, 인자)가 그대로 들어가는 자리입니다. 인자를 하나씩 추출하고 싶을 때는 $0, $1이라고 씁니다. 번호는 0부터 세기 때문에, /commit-msg 123 수정이라면 $0이 123, $1이 수정입니다. frontmatter의 arguments에서 인자에 이름을 붙이는 방식도 있습니다 (arguments: [issue, branch]라고 정의하면 본문에서 $issue, $branch라고 쓸 수 있습니다).
• argument-hint: 입력창에서 /commit-msg를 선택했을 때, 뒤에 무엇을 써야 하는지에 대한 입력 예시로서 흐릿하게 표시되는 문자열입니다. 스킬의 동작은 바꾸지 않고, 사용하는 사람을 위한 안내만 합니다.
• disable-model-invocation: true: 커밋 메시지 작성은 요구되지 않는 타이밍에 자동 실행되면 방해가 되므로, 명시적 호출 전용으로 설정합니다.

2-2. 자동 발동을 설계하기 (description 작성법)

자동 발동시키고 싶은 스킬에서는 반대로 disable-model-invocation을 붙이지 않고, description 작성법을 정교하게 만듭니다. Claude는 각 스킬의 description만을 보고 '지금 이 절차서가 필요한가'를 판단하기 때문입니다.

• "무엇을 하는 스킬인가"에 더해 "언제 사용하는가"를 작성합니다 (예: "~일 때 사용"). 보충 필드인 when_to_use도 병용할 수 있습니다.
• 스킬 목록상에서는 description과 when_to_use의 합계가 1,536자로 잘리기 때문에, 중요한 사용 시점을 맨 앞에 작성합니다.

또한, disable-model-invocation: true를 붙인 스킬은 description조차 상주하지 않게 되므로, 컨텍스트(Context) 절약 관점에서도 "자동 발동이 불필요한 것에는 반드시 붙인다"가 새로운 상식입니다.

2-3. 보조 파일과 스크립트 동봉하기

스킬 폴더에는 SKILL.md 이외의 파일도 둘 수 있습니다. 공식이 권장하는 구성은 다음과 같습니다.

skill-name/
├── SKILL.md # 절차의 본체 (500행 미만 권장)
├── reference.md # 상세한 사양·규약 (필요 시 Claude가 읽음)
...

포인트는 참조 파일은 Claude가 필요하다고 판단하여 읽었을 때만 컨텍스트에 포함되며, 스크립트는 실행 결과의 출력물만 포함된다는 점입니다. 매번 같은 절차로 끝나는 처리는 스크립트로 만들어 두면, 컨텍스트를 사용하지 않으면서 결과도 매번 동일하게 유지할 수 있습니다. 이 사용법은 3장의 레시피에서 실연합니다.

3. 응용·발전: 실용 레시피 모음과 팀 운영

여기서부터가 본 기사의 핵심입니다. 용도별 레시피를 소개합니다. 모두 실제로 구동하여 동작을 확인했습니다 (검증 환경은 기사 말미에 기재).

/review-style (참조 파일 동봉)

3-1. 레시피 1: 문체 체크. 사내의 문장 규약을 references/에 두고, 문서 작성 시 자동 발동시키는 스킬입니다.

---
name: review-style # 목록에 표시되는 표시 이름
description: 블로그 기사나 대외용 문서의 문체를 체크한다. 문장 리뷰 및 퇴고를 요청받았을 때 사용한다 # 「무엇을 하는가 + 언제 사용하는가」로 자동 발동되도록 설정
...

규약 전문(수천 자여도 가능)은 references/style-guide.md에 둡니다. 이 참조 파일은 1-1의 표에서 나타낸 단계적 읽기의 **레벨 3(보조 파일)**에 해당하며, 필요할 때만 읽힙니다. 따라서 CLAUDE.md에 작성하는 것과 달리, 코딩 작업 중의 컨텍스트 (Context)를 전혀 소비하지 않습니다. 실제로 /review-style이라고 입력하지 않아도, "이 문장을 퇴고해 주세요"라고 요청하는 것만으로 이 스킬이 자동 발동되어 규약 번호가 포함된 지적 사항이 돌아옵니다. description에 「언제 사용하는가」를 작성한 효과입니다 (2-2 참조).

/security-audit
(쓰기·실행 계열 도구 제외)

3-2. 레시피 2: 읽기 전용 보안 감사

disallowed-tools를 사용하면 스킬 실행 중에 Claude가 사용할 수 있는 도구(파일 편집, 커맨드 실행 등의 조작 수단)를 줄일 수 있습니다. 쓰기·실행 계열의 도구를 제외해 두면, "조사는 하되 변경은 하지 않는다"를 구조적으로 보장할 수 있습니다.

---
name: security-audit # 목록에 표시되는 표시 이름
description: 리포지토리 내의 기밀 정보 혼입이나 위험한 설정을 점검한다 # 설명문
...

프롬프트에 "수정하지 마"라고 쓰는 것만으로는 Claude가 지시를 잘못 읽었을 때 방지할 수 없습니다. 도구를 사용할 수 없는 상태로 만들어 두면, 잘못 읽더라도 쓸 방법이 없습니다. 실제로 이 스킬을 실행하는 중에 Write 도구로 쓰기를 시도하게 해도, 권한 에러로 거부되어 파일이 생성되지 않습니다. 또한, 제외할 도구는 환경에 맞춰 선택합니다. Windows에는 Bash와는 별개로 PowerShell 도구(PowerShell 커맨드를 직접 실행하는 도구)가 활성화되어 있는 환경이 있습니다 (공식 도구 레퍼런스에 목록이 있습니다). 이 환경에서 Bash만 제외하면, PowerShell을 경유한 셸 실행이라는 우회로가 남게 됩니다. 위의 예시에 PowerShell을 포함한 이유가 바로 이것입니다.

한 가지 주의할 점이 있습니다. 이름이 비슷한 allowed-tools는 "나열한 도구를 확인 없이 사용할 수 있도록 미리 허가해 두는" 필드이며, 그 외의 도구를 사용하지 못하게 하는 효과는 없습니다. 도구를 사용하지 못하게 하는 것은 disallowed-tools입니다. 이를 혼동하면 읽기 전용으로 의도한 감사 스킬이 실제로는 쓰기가 가능한 상태로 동작하게 됩니다.

/weekly-report
(스크립트 동봉)

3-3. 레시피 3: 주간 보고서 초안
집계는 스크립트에 맡기고, Claude에게는 문장화만 시키는 분업형 레시피입니다.

---
name: weekly-report # 목록에 표시되는 표시 이름
description: 이번 주 커밋 이력으로부터 주간 보고서 초안을 작성한다 # 설명문
...

# scripts/collect_commits.py
import subprocess
# 자신의 Git 사용자 이름을 가져온다
...

${CLAUDE_SKILL_DIR}는 "이 스킬의 폴더"를 가리키는 변수입니다. 이를 사용하면 스킬을 어디에 두더라도 스크립트를 올바르게 찾을 수 있습니다. 스크립트 본체의 코드는 컨텍스트 (Context)에 포함되지 않으므로, 집계 처리가 아무리 길어져도 컨텍스트 소비는 늘어나지 않습니다.

/deep-research
(context: fork)

3-4. 레시피 4: 조사를 서브 에이전트로 분리
2026년에 추가된 context: fork를 사용하면 스킬을 서브 에이전트 (메인 대화와는 별개의 Claude)로서 실행할 수 있습니다. 조사 과정에서 대량의 파일을 읽더라도, 읽은 내용은 서브 에이전트 측에 쌓이므로 메인 대화의 컨텍스트 (Context)를 소비하지 않습니다.

---
name: deep-research # 목록에 표시되는 표시 이름
description: 지정된 테마에 대해 코드베이스를 철저히 조사한다 # 설명문
...

agent에는 Explore 외에 Plan

・general-purpose

・직접 만든 서브 에이전트 이름을 지정할 수 있습니다. 진행 과정은 필요 없고 결론만 원하는 조사에 유용합니다.

3-5. 레시피 5: Hooks와 조합한 가드레일(Guardrail) 기반 배포

절차서(스킬 본문)는 Claude에게 요청하는 것이므로, 오해나 예외로 인해 깨질 가능성이 남아 있습니다. 깨졌을 때 사고가 되는 금지 사항은 1-3에서 정리했듯이 Hooks(정해진 처리를 반드시 실행하는 메커니즘)에 맡깁니다. 이 레시피에서는 '배포 절차'를 스킬에, 'main 브랜치 외에서의 배포 금지'를 Hooks에 분담시킵니다.

먼저, 스킬 본체는 절차서에만 전념하게 합니다.

---
name: deploy-staging # 목록에 표시되는 이름
description: 스테이징 환경으로 배포합니다 # 설명문
...

다음으로, 브랜치 검증의 훅 스크립트를 .claude/hooks/check-branch.sh에 놓습니다.

#!/bin/bash
# main 브랜치가 아니면 exit 2를 반환하여 도구 실행 자체를 차단합니다
branch=$(git rev-parse --abbrev-ref HEAD) # 현재 브랜치 이름을 가져옵니다
...

마지막으로, 이 스크립트를 .claude/settings.json의 Hooks에 등록합니다.

설명용 (주석 포함. JSON은 주석 불가하므로 그대로는 사용할 수 없습니다):

{
"hooks": {
"PreToolUse": [ // 도구 실행 직전에 개입하는 이벤트
...

붙여넣기용 (.claude/settings.json에 바로 사용 가능):

{
"hooks": {
"PreToolUse": [
...

실제로, develop 브랜치에서 /deploy-staging을 실행하면, 절차 1의 테스트 실행에 들어가기 전에 Hooks가 차단하며, '블록: main 브랜치 외에서는 배포할 수 없습니다 (현재: develop)'라고 표시됩니다. main 브랜치에서는 그대로 통과합니다. 스킬만으로는 '요청'에 그쳤던 금지 사항이, Hooks와의 조합으로 확실한 강제가 됩니다.

참고로, 이 예시의 matcher는 Bash 전체를 대상으로 하고 있기 때문에, main 외의 브랜치에서는 배포와 무관한 명령어 실행도 멈춥니다. 배포 전용 리포지토리 외에서 사용할 경우에는, 훅 스크립트 측에서 '명령어에 deploy.sh를 포함할 때만 차단한다'와 같이 조건을 좁혀야 합니다. 또한, 3-2에서 설명한 PowerShell 도구가 유효한 환경에서는, matcher가 Bash만으로는 PowerShell 경유의 명령어 실행을 차단할 수 없습니다. 양쪽을 대상으로 하려면 `

---
name: component-conventions # 목록에 표시되는 표시 이름
description: React 컴포넌트 구현 규약. 컴포넌트 신규 생성 및 수정 시 사용 # 설명문
...

user-invocable: false

를 추가하면, / 목록에서 사라지며 사람이 직접 호출할 수 없게 됩니다. Claude가 해당 폴더의 파일을 다룰 때만 자동으로 참조되는, 백그라운드용 규약 스킬 (Skill)이 됩니다. 실제로 src/components/ 하위 파일의 수정을 상담하면, Claude가 이 스킬의 규약 2가지를 스스로 제시합니다. 무관한 파일에 대한 상담에서는 발동하지 않습니다.

.claude/commands/

의 정리 및 이관 판단

3-7. 기존 통합 후의 동작 변화 (1-2)를 고려하면, 현재 가지고 있는 기존의 commands 파일은 다음 기준에 따라 하나씩 확인하는 것이 효율적입니다.

이관 작업 자체는 .claude/commands/review.md를 .claude/skills/review/SKILL.md로 옮기는 것뿐입니다. 동일한 이름이 공존하는 동안에는 Skills 측이 우선되므로, 이관 기간 중에 이중 실행될 걱정은 없습니다.

3-8. 팀 배포 및 통제

개인이 정교하게 만든 스킬을 팀에 확산하는 경로는 3가지가 있습니다.

• Project 스킬 (리포지토리를 clone한 모든 인원에게 동일한 스킬이 배포됩니다. 우선은 이것으로 충분합니다. .claude/skills/)를 Git에 커밋하기:
• Plugin으로서 배포하기: 여러 리포지토리에서 공통으로 사용하는 스킬 그룹은 플러그인화하여 마켓플레이스(Marketplace)를 통해 배포합니다.
• managed settings (조직 관리자 설정)로 배포하기: 전사 필수 스킬을 관리자가 일괄 배포합니다. 동일한 이름의 스킬 우선순위는 「Enterprise ＞ Personal ＞ Project」입니다.

managed settings를 사용하려면 조직 플랜(Organization Plan) 도입이 전제됩니다. Claude Team의 법인 도입을 검토 중이신 분들은 이 부분도 참고해 주세요.

배포뿐만 아니라, 제한하는 기능도 있습니다. 자작 스킬이라면 frontmatter에 disable-model-invocation: true를 작성하여 자동 발동을 멈출 수 있습니다. 하지만 관리자나 플러그인을 통해 배포된 스킬은 SKILL.md를 직접 편집할 수 없습니다 (편집해도 배포처의 업데이트로 인해 되돌아갑니다). 이때 사용하는 것이 settings.json의 skillOverrides입니다. 스킬 본체를 건드리지 않고, 받는 쪽에서 스킬별 노출 방식을 4단계 (on = 통상 / name-only = 이름만 / user-invocable-only = 사람만 호출 가능 / off = 무효)로 변경할 수 있습니다. 더욱 강력하게 차단하고 싶다면, Permission 규칙의 Skill(이름)을 사용하여 실행 자체를 허가하거나 거부할 수 있습니다. skillOverrides가 "어떻게 보여줄 것인가"를 담당한다면, Permission 규칙은 "실행하게 할 것인가"를 담당합니다.

해설용 (주석 포함. JSON은 주석을 지원하지 않으므로 이대로는 사용할 수 없습니다):

{
"skillOverrides": { // 키에 스킬 이름을 쓰고, 해당 스킬에만 적용
"deploy-staging": "user-invocable-only", // 자동 발동을 금지하고, 사람만 / 로 호출할 수 있는 상태로 설정
...

붙여넣기용 (.claude/settings.json 에 그대로 사용할 수 있습니다):

{
"skillOverrides": {
"deploy-staging": "user-invocable-only",
...

보충: 스킬 본문의 ! 커맨드``

실행 자체를 조직 차원에서 금지하고 싶다면, managed settings에서 disableSkillShellExecution: true를 설정합니다.

3-9. 보안: 외부 제작 스킬은 "소프트웨어 설치"로 취급할 것

스킬은 셸 실행(shell execution)과 파일 액세스(file access)를 동반하기 때문에, Anthropic 공식 측에서도 "신뢰할 수 있는 소스(자체 제작 또는 Anthropic 제공)의 스킬만 사용할 것"이라고 명확히 주의를 주고 있습니다. GitHub에 공개된 스킬 모음(skill sets)을 도입할 경우에는 최소한 다음 사항을 감사(audit)해야 합니다.

• SKILL.md 본문 및 스크립트에 외부 URL로 데이터를 전송하는 처리가 포함되어 있지 않은지
• ! 커맨드나 scripts/가 스킬의 목적과 무관한 파일(인증 정보 등)에 접근하고 있지 않은지
• description(설명)이 실제 처리 내용과 일치하는지 (목적을 위장한 스킬은 도구의 목적 외 사용으로 이어질 수 있습니다)

스킬은 기밀 정보를 포함하는 리포지토리(repository)에서도 동작합니다.