모범 사례
Claude를 위한 간결하고 신뢰할 수 있는 Agent Skills를 작성합니다.
Claude가 발견하고 성공적으로 사용할 수 있는 효과적인 Skills를 작성하는 방법을 배웁니다.
좋은 Skills는 간결하고, 구조가 명확하며, 실제 사용으로 테스트되어 있습니다. 이 가이드는 Claude가 발견하고 효과적으로 사용할 수 있는 Skills를 작성하기 위한 실용적인 작성 판단을 제공합니다.
Skills가 작동하는 방식에 대한 개념적 배경은 Skills 개요를 참조하세요.
핵심 원칙
간결함이 핵심
컨텍스트 창은 공유 자원입니다. Skill은 시스템 프롬프트, 대화 기록, 다른 Skills의 메타데이터, 실제 사용자 요청처럼 Claude가 알아야 하는 모든 것과 같은 컨텍스트 창을 공유합니다.
Skill의 모든 토큰이 즉시 비용을 발생시키는 것은 아닙니다. 시작 시에는 모든 Skills의 메타데이터(name과 description)만 미리 로드됩니다. Claude는 Skill이 관련될 때만 SKILL.md를 읽고, 추가 파일도 필요할 때만 읽습니다. 하지만 SKILL.md를 간결하게 유지하는 것은 여전히 중요합니다. Claude가 한 번 로드하면, 그 안의 모든 토큰은 대화 기록과 다른 문맥과 경쟁합니다.
기본 가정: Claude는 이미 매우 똑똑합니다.
Claude가 이미 알고 있는 문맥은 추가하지 마세요. 각 정보를 다음 질문으로 검토합니다.
- "Claude가 정말 이 설명을 필요로 하는가?"
- "Claude가 이것을 알고 있다고 가정할 수 있는가?"
- "이 문단은 토큰 비용을 정당화하는가?"
좋은 예: 간결함:
## Extract PDF text
Use pdfplumber for text extraction:
```python
import pdfplumber
with pdfplumber.open("file.pdf") as pdf:
text = pdf.pages[0].extract_text()
```나쁜 예: 너무 장황함:
## Extract PDF text
PDF (Portable Document Format) files are a common file format that contains
text, images, and other content. To extract text from a PDF, you'll need to
use a library. There are many libraries available for PDF processing, but we
recommend pdfplumber because it's easy to use and handles most cases well.
First, you'll need to install it using pip. Then you can use the code below...간결한 버전은 Claude가 PDF가 무엇인지, 라이브러리가 어떻게 작동하는지 알고 있다고 가정합니다.
적절한 자유도를 설정하기
작업의 취약성과 변동성에 맞춰 구체성 수준을 조정하세요.
높은 자유도는 여러 접근이 유효하고, 결정이 문맥에 따라 달라지며, 휴리스틱이 접근 방식을 이끌 때 적합합니다.
## Code review process
1. Analyze the code structure and organization
2. Check for potential bugs or edge cases
3. Suggest improvements for readability and maintainability
4. Verify adherence to project conventions중간 자유도는 선호 패턴이 있고, 일부 변형이 허용되며, 설정이 동작에 영향을 줄 때 적합합니다.
## Generate report
Use this template and customize as needed:
```python
def generate_report(data, format="markdown", include_charts=True):
# Process data
# Generate output in specified format
# Optionally include visualizations
```낮은 자유도는 작업이 취약하고 오류가 나기 쉬우며, 일관성이 중요하거나 특정 순서를 반드시 따라야 할 때 적합합니다.
## Database migration
Run exactly this script:
```bash
python scripts/migrate.py --verify --backup
```
Do not modify the command or add additional flags.Claude를 길을 탐색하는 로봇으로 생각하세요. 양쪽이 절벽인 좁은 다리에서는 안전한 경로가 하나뿐이므로 정확한 지시와 가드레일을 제공합니다. 위험이 없는 넓은 들판에서는 많은 경로가 성공으로 이어지므로 방향만 제시하고 Claude가 최적의 경로를 찾게 합니다.
사용할 모든 모델로 테스트하기
Skills는 모델에 추가되는 지식처럼 작동하므로 효과는 기반 모델에 따라 달라집니다. Skill을 사용할 모든 모델로 테스트하세요.
- Claude Haiku: 충분한 안내가 제공되는가?
- Claude Sonnet: 명확하고 효율적인가?
- Claude Opus: 과도하게 설명하지 않는가?
Opus에서 완벽한 지침도 Haiku에는 더 많은 세부 정보가 필요할 수 있습니다. 여러 모델에서 사용할 Skill이라면 모두에서 잘 작동하는 지침을 목표로 하세요.
Skill 구조
Note
YAML Frontmatter: SKILL.md frontmatter는 두 필드를 지원합니다.
name- 사람이 읽을 수 있는 Skill 이름(최대 64자)description- Skill이 무엇을 하고 언제 사용해야 하는지 설명하는 한 줄 설명(최대 1024자)
전체 구조는 Skills 개요를 참조하세요.
명명 규칙
Skills를 참조하고 논의하기 쉽게 하려면 일관된 명명 패턴을 사용하세요. Skill 이름에는 활동이나 능력을 명확히 설명하는 동명사형(verb + -ing)을 권장합니다.
좋은 이름 예시:
- "Processing PDFs"
- "Analyzing spreadsheets"
- "Managing databases"
- "Testing code"
- "Writing documentation"
허용 가능한 대안:
- 명사구: "PDF Processing", "Spreadsheet Analysis"
- 행동 중심: "Process PDFs", "Analyze Spreadsheets"
피해야 할 것:
- 모호한 이름: "Helper", "Utils", "Tools"
- 지나치게 일반적인 이름: "Documents", "Data", "Files"
- Skill 모음 안에서 일관되지 않은 패턴
일관된 이름은 문서와 대화에서 Skills를 참조하고, 한눈에 역할을 이해하고, 여러 Skills를 정리하고 검색하며, 전문적이고 통일된 Skill 라이브러리를 유지하는 데 도움이 됩니다.
효과적인 description 작성하기
description 필드는 Skill 발견을 가능하게 하며, Skill이 무엇을 하는지와 언제 사용하는지를 모두 포함해야 합니다.
Warning
항상 3인칭으로 작성하세요. description은 시스템 프롬프트에 주입됩니다. 관점이 일관되지 않으면 발견 문제가 생길 수 있습니다.
- 좋음: "Processes Excel files and generates reports"
- 피하기: "I can help you process Excel files"
- 피하기: "You can use this to process Excel files"
구체적으로 작성하고 핵심 용어를 포함하세요. 각 Skill에는 description 필드가 정확히 하나만 있습니다. Claude는 잠재적으로 100개가 넘는 Skills 중에서 올바른 Skill을 고르기 위해 이 설명을 사용합니다. description은 선택에 필요한 충분한 정보를 제공하고, 구현 세부 사항은 SKILL.md 본문에 둡니다.
효과적인 예:
description: Extract text and tables from PDF files, fill forms, merge documents. Use when working with PDF files or when the user mentions PDFs, forms, or document extraction.description: Analyze Excel spreadsheets, create pivot tables, generate charts. Use when analyzing Excel files, spreadsheets, tabular data, or .xlsx files.description: Generate descriptive commit messages by analyzing git diffs. Use when the user asks for help writing commit messages or reviewing staged changes.다음처럼 모호한 설명은 피하세요.
description: Helps with documentsdescription: Processes datadescription: Does stuff with files점진적 공개 패턴
SKILL.md는 온보딩 가이드의 목차처럼 Claude를 필요한 상세 자료로 안내하는 개요 역할을 합니다. 점진적 공개의 작동 방식은 Skills의 작동 방식을 참조하세요.
실용 지침:
- 최적 성능을 위해 SKILL.md 본문을 500줄 미만으로 유지하세요
- 이 한도에 가까워지면 내용을 별도 파일로 나누세요
- 아래 패턴을 사용해 지침, 코드, 리소스를 효과적으로 구성하세요
기본 Skill은 메타데이터와 지침이 들어 있는 SKILL.md 하나로 시작합니다.
Skill이 커지면 Claude가 필요할 때만 로드하는 추가 콘텐츠를 함께 묶을 수 있습니다.
완전한 Skill 디렉터리 구조는 다음과 같을 수 있습니다.
pdf/
|-- SKILL.md # Main instructions (loaded when triggered)
|-- FORMS.md # Form-filling guide (loaded as needed)
|-- reference.md # API reference (loaded as needed)
|-- examples.md # Usage examples (loaded as needed)
`-- scripts/
|-- analyze_form.py # Utility script (executed, not loaded)
|-- fill_form.py # Form filling script
`-- validate.py # Validation script패턴 1: 참조 파일로 안내하는 상위 수준 가이드
---
name: PDF Processing
description: Extracts text and tables from PDF files, fills forms, and merges documents. Use when working with PDF files or when the user mentions PDFs, forms, or document extraction.
---
# PDF Processing
## Quick start
Extract text with pdfplumber:
```python
import pdfplumber
with pdfplumber.open("file.pdf") as pdf:
text = pdf.pages[0].extract_text()
```
## Advanced features
**Form filling**: See [FORMS.md](FORMS.md) for complete guide
**API reference**: See [REFERENCE.md](REFERENCE.md) for all methods
**Examples**: See [EXAMPLES.md](EXAMPLES.md) for common patternsClaude는 필요할 때만 FORMS.md, REFERENCE.md, EXAMPLES.md를 로드합니다.
패턴 2: 도메인별 구성
여러 도메인을 가진 Skills에서는 관련 없는 문맥을 로드하지 않도록 도메인별로 내용을 구성하세요. 사용자가 sales metrics를 묻는다면 Claude는 sales 관련 스키마만 필요하며 finance나 marketing 데이터는 필요하지 않습니다.
bigquery-skill/
|-- SKILL.md (overview and navigation)
`-- reference/
|-- finance.md (revenue, billing metrics)
|-- sales.md (opportunities, pipeline)
|-- product.md (API usage, features)
`-- marketing.md (campaigns, attribution)# BigQuery Data Analysis
## Available datasets
**Finance**: Revenue, ARR, billing -> See [reference/finance.md](reference/finance.md)
**Sales**: Opportunities, pipeline, accounts -> See [reference/sales.md](reference/sales.md)
**Product**: API usage, features, adoption -> See [reference/product.md](reference/product.md)
**Marketing**: Campaigns, attribution, email -> See [reference/marketing.md](reference/marketing.md)
## Quick search
Find specific metrics using grep:
```bash
grep -i "revenue" reference/finance.md
grep -i "pipeline" reference/sales.md
grep -i "api usage" reference/product.md
```패턴 3: 조건부 세부 정보
기본 내용을 보여 주고 고급 내용으로 연결합니다.
# DOCX Processing
## Creating documents
Use docx-js for new documents. See [DOCX-JS.md](DOCX-JS.md).
## Editing documents
For simple edits, modify the XML directly.
**For tracked changes**: See [REDLINING.md](REDLINING.md)
**For OOXML details**: See [OOXML.md](OOXML.md)Claude는 사용자가 해당 기능을 필요로 할 때만 REDLINING.md나 OOXML.md를 읽습니다.
깊게 중첩된 참조 피하기
Claude는 참조 파일에서 다시 참조된 파일을 읽을 때 일부만 읽을 수 있습니다. 중첩 참조를 만나면 전체 파일을 읽기보다 head -100 같은 명령으로 미리 보기만 해 정보가 불완전해질 수 있습니다.
참조는 SKILL.md에서 한 단계 깊이로 유지하세요. 모든 참조 파일은 SKILL.md에서 직접 링크되어야 Claude가 필요할 때 전체 파일을 읽을 수 있습니다.
# Bad
SKILL.md -> advanced.md -> details.md
# Good
SKILL.md links directly to advanced.md, reference.md, and examples.md긴 참조 파일에는 목차 넣기
100줄이 넘는 참조 파일은 맨 위에 목차를 넣으세요. Claude가 부분 읽기를 하더라도 가능한 정보의 전체 범위를 볼 수 있습니다.
# API Reference
## Contents
- Authentication and setup
- Core methods (create, read, update, delete)
- Advanced features (batch operations, webhooks)
- Error handling patterns
- Code examples워크플로와 피드백 루프
복잡한 작업에는 워크플로 사용하기
복잡한 작업은 명확하고 순차적인 단계로 나누세요. 특히 복잡한 워크플로에는 Claude가 답변에 복사해 진행 상황을 체크할 수 있는 체크리스트를 제공합니다.
## Research synthesis workflow
Copy this checklist and track your progress:
```
Research Progress:
- [ ] Step 1: Read all source documents
- [ ] Step 2: Identify key themes
- [ ] Step 3: Cross-reference claims
- [ ] Step 4: Create structured summary
- [ ] Step 5: Verify citations
```
**Step 1: Read all source documents**
Review each document in the `sources/` directory. Note the main arguments and supporting evidence.
**Step 2: Identify key themes**
Look for patterns across sources. What themes appear repeatedly? Where do sources agree or disagree?
**Step 3: Cross-reference claims**
For each major claim, verify it appears in the source material. Note which source supports each point.
**Step 4: Create structured summary**
Organize findings by theme. Include main claim, supporting evidence, and conflicting viewpoints.
**Step 5: Verify citations**
Check that every claim references the correct source document. If citations are incomplete, return to Step 3.코드가 필요 없는 분석 작업에도 워크플로가 적용됩니다. 체크리스트 패턴은 복잡한 다단계 프로세스에 사용할 수 있습니다.
## PDF form filling workflow
Copy this checklist and check off items as you complete them:
```
Task Progress:
- [ ] Step 1: Analyze the form (run analyze_form.py)
- [ ] Step 2: Create field mapping (edit fields.json)
- [ ] Step 3: Validate mapping (run validate_fields.py)
- [ ] Step 4: Fill the form (run fill_form.py)
- [ ] Step 5: Verify output (run verify_output.py)
```
Run: `python scripts/analyze_form.py input.pdf`
Edit `fields.json` to add values.
Run: `python scripts/validate_fields.py fields.json`
Run: `python scripts/fill_form.py input.pdf fields.json output.pdf`
Run: `python scripts/verify_output.py output.pdf`
If verification fails, return to Step 2.명확한 단계는 Claude가 중요한 검증을 건너뛰지 않도록 합니다.
피드백 루프 구현하기
일반 패턴: validator 실행 -> 오류 수정 -> 반복.
이 패턴은 출력 품질을 크게 높입니다. 코드가 없는 Skills에서는 STYLE_GUIDE.md 같은 참조 문서를 읽고 비교하는 방식이 validator가 됩니다. 코드가 있는 Skills에서는 python ooxml/scripts/validate.py unpacked_dir/처럼 즉시 검증하고, 실패하면 오류 메시지를 읽고 XML을 고친 뒤 검증을 반복합니다. 검증이 통과할 때만 재패키징하고 결과 문서를 테스트합니다.
콘텐츠 지침
시간에 민감한 정보 피하기
곧 오래될 정보를 포함하지 마세요.
# Bad
If you're doing this before August 2025, use the old API.
After August 2025, use the new API.
# Good
## Current method
Use the v2 API endpoint: `api.example.com/v2/messages`
## Old patterns
<details>
<summary>Legacy v1 API (deprecated 2025-08)</summary>
The v1 API used: `api.example.com/v1/messages`
This endpoint is no longer supported.
</details>오래된 패턴 섹션은 메인 내용을 어지럽히지 않고 역사적 맥락을 제공합니다.
용어를 일관되게 사용하기
한 용어를 선택하고 Skill 전체에서 유지하세요.
- 좋음: 항상 "API endpoint", "field", "extract"
- 나쁨: "API endpoint", "URL", "API route", "path"를 섞어 사용
- 나쁨: "field", "box", "element", "control"을 섞어 사용
일관성은 Claude가 지침을 이해하고 따르는 데 도움이 됩니다.
공통 패턴
템플릿 패턴
출력 형식 템플릿을 제공합니다. 필요한 엄격함에 맞게 조정하세요.
## Report structure
ALWAYS use this exact template structure:
```markdown
# [Analysis Title]
## Executive summary
[One-paragraph overview of key findings]
## Key findings
- Finding 1 with supporting data
- Finding 2 with supporting data
- Finding 3 with supporting data
## Recommendations
1. Specific actionable recommendation
2. Specific actionable recommendation
```유연성이 필요할 때는 기본 형식을 제시하되, 분석 내용에 따라 Claude가 섹션을 조정하도록 허용합니다.
예제 패턴
출력 품질이 예제를 보는 것에 달려 있는 Skills에서는 일반 프롬프트처럼 입력/출력 쌍을 제공합니다.
## Commit message format
Generate commit messages following these examples:
**Example 1:**
Input: Added user authentication with JWT tokens
Output:
```
feat(auth): implement JWT-based authentication
Add login endpoint and token validation middleware
```
**Example 2:**
Input: Fixed bug where dates displayed incorrectly in reports
Output:
```
fix(reports): correct date formatting in timezone conversion
Use UTC timestamps consistently across report generation
```
Follow this style: type(scope): brief description, then detailed explanation.예제는 설명만으로는 전달하기 어려운 스타일과 상세 수준을 명확히 보여 줍니다.
조건부 워크플로 패턴
Claude가 판단 지점을 통과하도록 안내합니다.
## Document modification workflow
1. Determine the modification type:
**Creating new content?** -> Follow "Creation workflow" below
**Editing existing content?** -> Follow "Editing workflow" below
2. Creation workflow:
- Use docx-js library
- Build document from scratch
- Export to .docx format
3. Editing workflow:
- Unpack existing document
- Modify XML directly
- Validate after each change
- Repack when completeTip
워크플로가 크고 복잡해지면 별도 파일로 옮기고, 현재 작업에 맞는 파일을 읽도록 Claude에게 알려 주세요.
평가와 반복
먼저 평가 만들기
긴 문서를 쓰기 전에 평가를 만드세요. 이렇게 하면 상상한 문제가 아니라 실제 문제를 Skill이 해결하는지 확인할 수 있습니다.
- Skill 없이 대표 작업을 Claude에게 실행시켜 실패나 부족한 문맥을 기록합니다
- 그 격차를 테스트하는 세 가지 시나리오를 만듭니다
- Skill 없이 기준 성능을 측정합니다
- 격차를 메우고 평가를 통과할 최소 지침을 작성합니다
- 평가를 실행하고 기준과 비교하며 개선합니다
{
"skills": ["pdf-processing"],
"query": "Extract all text from this PDF file and save it to output.txt",
"files": ["test-files/document.pdf"],
"expected_behavior": [
"Successfully reads the PDF file using an appropriate PDF processing library or command-line tool",
"Extracts text content from all pages in the document without missing any pages",
"Saves the extracted text to a file named output.txt in a clear, readable format"
]
}Note
이 예시는 간단한 테스트 기준을 가진 데이터 기반 평가입니다. 현재 이러한 평가를 실행하는 내장 방법은 제공하지 않습니다. 사용자가 직접 평가 시스템을 만들 수 있으며, 평가는 Skill 효과를 측정하는 기준입니다.
Claude와 반복적으로 Skills 개발하기
가장 효과적인 Skill 개발에는 Claude 자체가 포함됩니다. Claude A와 함께 Skill을 만들고, 새 인스턴스인 Claude B가 실제 작업에서 사용하게 하세요. Claude A는 지침을 설계하고 다듬는 데 도움을 주고, Claude B는 실제 작업에서 이를 테스트합니다.
새 Skill을 만들 때는 먼저 Skill 없이 Claude A와 작업을 완료하고, 반복해서 제공한 문맥과 절차 지식을 관찰합니다. 그런 다음 재사용 가능한 패턴을 식별하고 Claude A에게 "방금 사용한 BigQuery 분석 패턴을 담은 Skill을 만들어 줘. 테이블 스키마, 명명 규칙, test accounts 필터링 규칙을 포함해"처럼 요청합니다. Claude A가 불필요한 설명을 넣지 않았는지 검토하고, 스키마 같은 긴 정보는 별도 참조 파일로 분리하도록 구성합니다. 그 후 Claude B로 유사 작업을 테스트하고 관찰 결과를 Claude A에게 되돌려 개선합니다.
기존 Skills도 같은 방식으로 개선합니다. Claude B가 실제 워크플로에서 어디서 막히는지, 어떤 규칙을 놓치는지 관찰하고, 현재 SKILL.md와 함께 Claude A에게 전달합니다. Claude A의 제안(규칙을 더 눈에 띄게 만들기, "always filter"를 "MUST filter"로 바꾸기, 워크플로 재구성 등)을 검토하고 다시 테스트합니다.
팀과 공유할 때는 Skill이 예상대로 활성화되는지, 지침이 명확한지, 무엇이 빠졌는지 피드백을 모으세요. 이 접근 방식은 Claude A의 에이전트 지식, 사용자의 도메인 전문성, Claude B의 실제 사용 관찰을 결합합니다.
Claude가 Skills를 탐색하는 방식 관찰하기
Claude가 파일을 예상과 다른 순서로 읽는지, 중요한 참조를 놓치는지, 특정 파일에 지나치게 의존하는지, 번들 파일을 전혀 열지 않는지 관찰하세요. 이러한 관찰은 구조가 직관적인지, 링크가 충분히 명확한지, 어떤 내용을 메인 SKILL.md로 옮겨야 하는지 알려 줍니다. name과 description은 Claude가 Skill을 트리거할지 결정할 때 특히 중요합니다.
피해야 할 안티패턴
Windows 스타일 경로 피하기
Windows에서도 파일 경로에는 항상 슬래시를 사용하세요.
- 좋음:
scripts/helper.py,reference/guide.md - 피하기:
scripts\helper.py,reference\guide.md
Unix 스타일 경로는 모든 플랫폼에서 작동하지만 Windows 스타일 경로는 Unix 시스템에서 오류를 일으킵니다.
너무 많은 선택지 제공 피하기
필요하지 않다면 여러 접근법을 나열하지 마세요.
**Bad example: Too many choices**:
"You can use pypdf, or pdfplumber, or PyMuPDF, or pdf2image, or..."
**Good example: Provide a default**:
"Use pdfplumber for text extraction:
```python
import pdfplumber
```
For scanned PDFs requiring OCR, use pdf2image with pytesseract instead."고급: 실행 가능한 코드를 포함한 Skills
다음 섹션은 실행 가능한 스크립트를 포함하는 Skills에 초점을 맞춥니다. Markdown 지침만 사용하는 Skill이라면 효과적인 Skills 체크리스트로 건너뛰어도 됩니다.
회피하지 말고 해결하기
Skills용 스크립트를 작성할 때는 오류 조건을 Claude에게 떠넘기지 말고 직접 처리하세요.
def process_file(path):
"""Process a file, creating it if it doesn't exist."""
try:
with open(path) as f:
return f.read()
except FileNotFoundError:
print(f"File {path} not found, creating default")
with open(path, 'w') as f:
f.write('')
return ''
except PermissionError:
print(f"Cannot access {path}, using default")
return ''반대로 return open(path).read()처럼 실패만 하고 Claude가 알아서 하게 하는 코드는 피하세요. 설정값도 "voodoo constants"가 되지 않도록 이유를 문서화합니다.
# HTTP requests typically complete within 30 seconds
REQUEST_TIMEOUT = 30
# Three retries balances reliability vs speed
MAX_RETRIES = 3유틸리티 스크립트 제공하기
Claude가 스크립트를 작성할 수 있더라도 미리 만든 스크립트는 더 신뢰할 수 있고, 토큰과 시간을 절약하며, 사용 간 일관성을 보장합니다.
지침에서 Claude가 스크립트를 실행해야 하는지, 아니면 참조로 읽어야 하는지 명확히 하세요. 대부분의 유틸리티 스크립트는 실행하는 편이 더 안정적이고 효율적입니다.
## Utility scripts
**analyze_form.py**: Extract all form fields from PDF
```bash
python scripts/analyze_form.py input.pdf > fields.json
```
**validate_boxes.py**: Check for overlapping bounding boxes
```bash
python scripts/validate_boxes.py fields.json
```
**fill_form.py**: Apply field values to PDF
```bash
python scripts/fill_form.py input.pdf fields.json output.pdf
```시각 분석 사용하기
입력을 이미지로 렌더링할 수 있다면 Claude가 시각적으로 분석하게 하세요.
## Form layout analysis
1. Convert PDF to images:
```bash
python scripts/pdf_to_images.py form.pdf
```
2. Analyze each page image to identify form fields
3. Claude can see field locations and types visuallyNote
이 예시에서는 pdf_to_images.py 스크립트를 작성해야 합니다.
검증 가능한 중간 출력 만들기
복잡하고 개방적인 작업에서는 Claude가 실수할 수 있습니다. "plan-validate-execute" 패턴은 Claude가 먼저 구조화된 계획을 만들고, 스크립트로 검증한 뒤 실행하게 하여 오류를 일찍 잡습니다. 예를 들어 스프레드시트를 기반으로 PDF의 50개 필드를 업데이트한다면, 중간 changes.json을 만들고 검증한 다음 적용합니다. 흐름은 analyze -> create plan file -> validate plan -> execute -> verify입니다.
이 패턴은 변경 적용 전에 오류를 찾고, 기계적으로 검증 가능하며, 원본을 건드리지 않고 계획을 반복할 수 있고, 오류 메시지가 특정 문제를 가리키게 합니다. 배치 작업, 파괴적 변경, 복잡한 검증 규칙, 중요한 작업에 사용하세요.
의존성 패키징하기
Skills는 플랫폼별 제한이 있는 코드 실행 환경에서 실행됩니다.
- claude.ai: npm과 PyPI에서 패키지를 설치하고 GitHub 저장소에서 가져올 수 있습니다
- Anthropic API: 네트워크 접근과 런타임 패키지 설치가 없습니다
필요한 패키지를 SKILL.md에 나열하고 코드 실행 도구 문서에서 사용할 수 있는지 확인하세요.
런타임 환경
Skills는 파일 시스템 접근, bash 명령, 코드 실행 기능이 있는 환경에서 실행됩니다. 시작 시 모든 Skills의 name과 description이 시스템 프롬프트에 로드되고, Claude는 필요할 때 SKILL.md와 다른 파일을 읽습니다. 유틸리티 스크립트는 전체 내용을 컨텍스트에 넣지 않고 bash로 실행할 수 있으며, 출력만 토큰을 소비합니다. 큰 참조 파일이나 데이터는 실제로 읽기 전까지 컨텍스트 비용이 없습니다.
작성 시에는 슬래시 경로를 쓰고, 설명적인 파일명을 선택하고, 도메인이나 기능별로 정리하고, 결정적인 작업에는 스크립트를 선호하며, "Run analyze_form.py"와 "See analyze_form.py"처럼 실행 의도를 명확히 하세요. 실제 요청으로 Claude가 디렉터리 구조를 탐색할 수 있는지도 테스트해야 합니다.
MCP 도구 참조
Skill이 MCP(Model Context Protocol) 도구를 사용한다면 "tool not found" 오류를 피하기 위해 항상 완전한 도구 이름을 사용하세요.
형식: ServerName:tool_name
Use the BigQuery:bigquery_schema tool to retrieve table schemas.
Use the GitHub:create_issue tool to create issues.도구가 설치되어 있다고 가정하지 않기
패키지가 있다고 가정하지 마세요.
**Bad example: Assumes installation**:
"Use the pdf library to process the file."
**Good example: Explicit about dependencies**:
"Install required package: `pip install pypdf`
Then use it:
```python
from pypdf import PdfReader
reader = PdfReader("file.pdf")
```기술 메모
YAML frontmatter 요구 사항
SKILL.md frontmatter에는 name(최대 64자)과 description(최대 1024자)만 포함됩니다. 전체 구조는 Skills 개요를 참조하세요.
토큰 예산
최적 성능을 위해 SKILL.md 본문은 500줄 미만으로 유지하세요. 넘는다면 앞서 설명한 점진적 공개 패턴으로 별도 파일로 나눕니다.
효과적인 Skills 체크리스트
핵심 품질
- Description이 구체적이고 핵심 용어를 포함한다
- Description이 Skill의 기능과 사용 시점을 모두 포함한다
- SKILL.md 본문이 500줄 미만이다
- 필요한 추가 세부 정보가 별도 파일에 있다
- 시간에 민감한 정보가 없다(또는 "old patterns" 섹션에 있다)
- 용어가 일관적이다
- 예제가 추상적이지 않고 구체적이다
- 파일 참조가 한 단계 깊이다
- 점진적 공개를 적절히 사용한다
- 워크플로 단계가 명확하다
코드와 스크립트
- 스크립트가 Claude에게 떠넘기지 않고 문제를 해결한다
- 오류 처리가 명시적이고 유용하다
- "voodoo constants"가 없다
- 필요한 패키지가 지침에 나열되고 사용 가능성이 확인됐다
- 스크립트 문서가 명확하다
- Windows 스타일 경로가 없다
- 중요한 작업에 검증 단계가 있다
- 품질이 중요한 작업에는 피드백 루프가 포함된다
테스트
- 최소 세 가지 평가를 만들었다
- Haiku, Sonnet, Opus로 테스트했다
- 실제 사용 시나리오로 테스트했다
- 해당되는 경우 팀 피드백을 반영했다
클로데스킬스 문서