Claude용 스킬(Skills) 만들기: 단계와 예시 | Claude

스킬(Skills)은 특정 작업이나 도메인을 위해 Claude의 역량을 확장하는 맞춤형 지침입니다.

SKILL.md 파일로 스킬을 만들면, 특정 상황을 더 효과적으로 처리하는 방법을 Claude에게 가르칠 수 있습니다. 스킬의 강점은 조직의 지식을 코드화하고, 출력물을 표준화하며, 반복 설명이나 커스텀 에이전트 구축 없이도 복잡한 다단계 워크플로를 처리할 수 있다는 데 있습니다.

skill creator 템플릿을 사용하거나 수동으로 작성해, Claude를 범용 비서에서 여러분의 워크플로에 특화된 전문가로 바꿔보세요. (팁: 더 쉽게 시작하려면 이 템플릿으로 SKILL.md를 만든 뒤, 필요한 부분만 맞춤화하는 것을 권장합니다.)

5단계로 스킬 만들기

더 안정적으로 트리거되는 스킬을 만들기 위해 아래의 구조적 접근법을 따르세요.

1) 핵심 요구사항 이해하기

무언가를 쓰기 전에, 이 스킬이 어떤 문제를 해결하는지 명확히 하세요. 좋은 스킬은 측정 가능한 결과가 있는 구체적인 니즈를 다룹니다. 예를 들어, “재무 관련을 도와줘”보다 “PDF에서 재무 데이터를 추출해 CSV로 포맷팅해줘”가 더 좋습니다. 입력 형식, 수행 작업, 기대 출력이 명확하기 때문입니다.

다음 질문으로 시작하세요.

• 이 스킬이 수행하는 구체적인 작업은 무엇인가?
• 어떤 트리거(요청/상황)에서 활성화되어야 하는가?
• 성공의 기준은 무엇인가?
• 엣지 케이스나 한계는 무엇인가?

2) 이름 작성하기

스킬에는 3가지 핵심 요소가 필요합니다.

• name(식별 가능한 명확한 이름)
• description(언제 활성화할지)
• instructions(어떻게 실행할지)

실제로 SKILL.md에서 트리거링(Claude가 스킬을 호출할지 결정하는 것) 에 영향을 주는 것은 name과 description뿐입니다. 즉, Claude가 특화 지식/워크플로를 위해 스킬을 부를 수 있게 만드는 요소는 이 둘입니다.

이름은 단순하고 설명적이어야 합니다. 소문자와 하이픈을 사용하세요(예: pdf-editor, brand-guidelines). 짧고 명확하게 유지합니다.

3) description 필드 작성하기

description은 스킬이 언제 활성화되는지를 결정하므로 가장 중요한 구성 요소입니다. Claude의 관점에서, 트리거/역량/사용 사례에 초점을 맞춰 작성하세요.

좋은 description은 다음 요소들의 균형을 잡습니다.

• 구체적인 역량
• 명확한 트리거
• 관련 맥락
• 경계(무엇을 하지 않는지)

약한 description:

markdown
This skill helps with PDFs and documents.

강한 description:

markdown
Comprehensive PDF manipulation toolkit for extracting text and tables, creating new PDFs, merging/splitting documents, and handling forms. When Claude needs to fill in a PDF form or programmatically process, generate, or analyze PDF documents at scale. Use for document workflows and batch operations. Not for simple PDF viewing or basic conversions.

강한 버전은 Claude에게 여러 데이터 포인트를 줍니다. 구체 동사(추출, 생성, 병합), 구체적인 사용 사례(폼 채우기, 배치 작업), 명확한 경계(단순 보기용은 아님)가 포함됩니다.

4) 본문 지침(instructions) 작성하기

지침은 구조적이고, 훑어보기 쉬우며, 실행 가능해야 합니다. 마크다운 헤더를 사용하고, 선택지는 불릿으로, 예시는 코드 블록으로 제공하세요.

명확한 계층으로 구성하세요: 개요, 전제조건, 실행 단계, 예시, 오류 처리, 한계. 복잡한 워크플로는 입력/출력이 명확한 개별 단계로 나누세요.

올바른 사용법을 보여주는 구체적 예시를 포함하세요. 오용을 막고 기대치를 관리하기 위해, 스킬이 할 수 없는 일도 명시하세요. SKILL.md에는 추가 참조 파일과 자산을 포함할 수도 있어, 스킬이 트리거될 때 에이전트에게 무엇을 하라고 요청하는지 더 명확히 안내할 수 있습니다.

5) 스킬 업로드하기

어느 Claude 환경에서 만드는지에 따라 업로드 방법이 다릅니다.

• Claude.ai (Claude 앱): Settings로 가서 커스텀 스킬을 추가하세요. 커스텀 스킬은 코드 실행이 활성화된 Pro/Max/Team/Enterprise 플랜이 필요합니다. 여기 업로드한 스킬은 사용자 개인 단위로만 적용되며, 조직 전체에 공유되지 않고 관리자가 중앙에서 관리할 수도 없습니다.

• Claude Code: 플러그인 또는 프로젝트 루트에 skills/ 디렉터리를 만들고, SKILL.md가 들어 있는 스킬 폴더들을 추가하세요. 플러그인이 설치되면 Claude가 자동으로 발견하고 사용합니다. 예시 구조:

markdown
my-project/
├── skills/
│   └── my-skill/
│       └── SKILL.md

• Claude Developer Platform: Skills API(/v1/skills 엔드포인트)를 통해 업로드하세요. 필요한 베타 헤더와 함께 POST 요청을 사용합니다.

markdown
curl -X POST "https://api.anthropic.com/v1/skills" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: skills-2025-10-02" \
  -F "display_title=My Skill Name" \
  -F "files[]=@my-skill/SKILL.md;filename=my-skill/SKILL.md"

4) 테스트 및 검증

배포 전에 현실적인 시나리오로 스킬을 테스트하세요. 체계적인 테스트는 지침의 빈틈, description의 모호함, 실제 사용에서만 드러나는 엣지 케이스를 찾아줍니다.

다음 세 가지 시나리오를 포함하는 테스트 매트릭스를 만드세요.

• 정상 동작: 스킬이 완벽히 처리해야 하는 전형적인 요청으로 테스트합니다. 재무 분석 스킬이라면 “Microsoft의 최신 실적을 분석해줘” 또는 “이 10-K 공시로 datapack을 만들어줘” 같은 요청이 해당됩니다. 이런 기준 테스트로 지침이 의도대로 작동하는지 확인합니다.

• 엣지 케이스: 불완전하거나 이례적인 입력으로 테스트합니다. 데이터가 누락되면? 파일 형식이 예상과 다르면? 사용자가 모호한 지시를 하면? 스킬은 이런 경우에도 우아하게 처리해야 합니다. 품질이 다소 낮아져도 유용한 결과를 내거나, 진행을 위해 무엇이 필요한지 설명해야 합니다.

• 범위 밖(out-of-scope) 요청: 관련 있어 보이지만 스킬이 트리거되면 안 되는 작업을 요청해봅니다. NDA 검토 스킬이라면 “이 고용 계약서를 검토해줘” 또는 “이 임대차 계약을 분석해줘” 같은 요청을 시도해보세요. 스킬은 비활성 상태로 남아 다른 스킬이나 Claude의 일반 기능이 처리하도록 해야 합니다.

더 깊은 검증을 위해 다음 테스트도 고려하세요.

• 트리거링 테스트: 기대한 때에 스킬이 활성화되나요? 명시적 요청(“재무 datapack 스킬로 이 회사를 분석해줘”)과 자연스러운 요청(“이 회사 재무를 이해하도록 도와줘”) 모두로 테스트하세요. 무관한 상황에서 비활성 상태를 유지하나요? 잘 스코프된 스킬은 “언제 활성화하지 말아야 하는지”도 압니다. 비슷하지만 다른 요청으로 경계를 검증하세요.

• 기능 테스트: 출력 일관성(유사 입력을 여러 번 실행했을 때 결과가 비슷한가?), 사용성(도메인에 익숙하지 않은 사람도 성공적으로 쓸 수 있는가?), 문서 정확성(예시가 실제 동작과 일치하는가?) 등을 확인합니다.

5) 사용 결과를 바탕으로 반복 개선하기

실사용에서 스킬이 어떻게 동작하는지 관찰하세요. 트리거링이 일관되지 않다면 description을 다듬고, 출력이 예상외로 들쭉날쭉하다면 지침을 명확히 하세요. 프롬프트와 마찬가지로, 최고의 스킬은 실전 적용을 통해 진화합니다.

스킬 제작을 위한 일반 모범 사례

이 원칙들은 스킬이 이론적인 문서가 아니라 유지보수 가능하고 재사용 가능하며 실제로 유용한 자산이 되도록 돕습니다.

사용 사례에서 시작하기

추측으로 스킬을 쓰지 마세요. 실제로 반복되는 작업이 있을 때 만드세요. 최고의 스킬은 여러분이 자주 마주치는 문제를 해결합니다.

만들기 전에 자문하세요.

• 이 작업을 최소 5번 이상 해봤는가?
• 앞으로도 최소 10번은 더 하게 될 것 같은가?

둘 다 “예”라면 스킬을 만들 이유가 충분합니다.

성공 기준을 정의하고—스킬에 포함하기

Claude에게 “좋은 결과물”이 무엇인지 알려주세요. 재무 보고서를 만든다면, 필수 섹션, 형식 기준, 검증 체크, 품질 임계값을 명시하세요. Claude가 스스로 점검할 수 있도록 이 기준을 지침에 포함합니다.

Skill-Creator 스킬 사용하기

skill-creator 스킬은 구조가 잘 잡힌 스킬을 만들도록 안내합니다. 명확화 질문을 던지고, description 개선을 제안하며, 지침 포맷을 올바르게 잡아줍니다. GitHub Skills 리포지토리와 Claude.ai에서 제공되며, 특히 첫 몇 개 스킬을 만들 때 유용합니다.

스킬의 한계와 고려사항

스킬이 어떻게 동작하는지—그리고 그 경계가 어디인지—를 이해하면 더 효과적인 스킬을 설계하고 적절한 기대치를 설정할 수 있습니다.

스킬 트리거링

Claude는 요청과 스킬 description을 비교해 관련성을 판단합니다. 키워드 매칭이 아니라 의미 기반(semantic) 으로 이해합니다. 하지만 description이 모호하면 트리거링 정확도가 떨어집니다.

복잡한 작업에서 서로 다른 측면을 다루는 여러 스킬이 동시에 활성화될 수도 있습니다. 지나치게 일반적인 description은 부적절한 활성화를 유발하고, 반대로 필요한 사용 사례가 누락되면 활성화가 빠질 수 있습니다.

적절한 파일 크기

스킬을 작성할 때 불필요한 내용으로 컨텍스트 윈도우를 부풀리지 마세요. 각 정보가 매번 로드되어야 하는지, 아니면 특정 조건에서만 필요할지를 고민하세요.

“메뉴(menu)” 접근을 사용하세요. 스킬이 여러 상이한 프로세스/옵션을 포함한다면, SKILL.md는 가능한 것들을 개괄하고, 각 항목에 대해 별도 파일을 상대경로로 참조하게 하세요. 그러면 Claude는 사용자의 작업에 관련된 파일만 읽고, 대화에 필요 없는 다른 파일은 읽지 않습니다.

이 별도 파일들이 상호 배타적일 필요는 없습니다. 핵심 원칙은 내용을 적절한 덩어리로 나누고, 작업에 따라 Claude가 필요한 것을 선택하도록 하는 것입니다.

실전 스킬 예시

스킬 예시 #1: docx 생성 스킬

markdown
#---
name: docx
description: "Comprehensive document creation, editing, and analysis with support for tracked changes, comments, formatting preservation, and text extraction. When Claude needs to work with professional documents (.docx files) for: (1) Creating new documents, (2) Modifying or editing content, (3) Working with tracked changes, (4) Adding comments, or any other document tasks"
license: Proprietary. LICENSE.txt has complete terms
---

# DOCX creation, editing, and analysis

## Overview

A user may ask you to create, edit, or analyze the contents of a .docx file. A .docx file is essentially a ZIP archive containing XML files and other resources that you can read or edit. You have different tools and workflows available for different tasks.

## Workflow Decision Tree

### Reading/Analyzing Content
Use "Text extraction" or "Raw XML access" sections below

### Creating New Document
Use "Creating a new Word document" workflow

### Editing Existing Document
- **Your own document + simple changes**
  Use "Basic OOXML editing" workflow

- **Someone else's document**
  Use **"Redlining workflow"** (recommended default)

- **Legal, academic, business, or government docs**
  Use **"Redlining workflow"** (required)

## Reading and analyzing content

### Text extraction
If you just need to read the text contents of a document, you should convert the document to markdown using pandoc. Pandoc provides excellent support for preserving document structure and can show tracked changes:

```bash
# Convert document to markdown with tracked changes
pandoc --track-changes=all path-to-file.docx -o output.md
# Options: --track-changes=accept/reject/all

Raw XML access

You need raw XML access for: comments, complex formatting, document structure, embedded media, and metadata. For any of these features, you'll need to unpack a document and read its raw XML contents.

Unpacking a file

python ooxml/scripts/unpack.py <office_file> <output_directory>

Key file structures

• word/document.xml - Main document contents
• word/comments.xml - Comments referenced in document.xml
• word/media/ - Embedded images and media files
• Tracked changes use <w:ins> (insertions) and <w:del> (deletions) tags

Creating a new Word document

When creating a new Word document from scratch, use docx-js, which allows you to create Word documents using JavaScript/TypeScript.

Workflow

1. MANDATORY - READ ENTIRE FILE: Read docx-js.md (~500 lines) completely from start to finish. NEVER set any range limits when reading this file. Read the full file content for detailed syntax, critical formatting rules, and best practices before proceeding with document creation.
2. Create a JavaScript/TypeScript file using Document, Paragraph, TextRun components (You can assume all dependencies are installed, but if not, refer to the dependencies section below)
3. Export as .docx using Packer.toBuffer()

Editing an existing Word document

When editing an existing Word document, use the Document library (a Python library for OOXML manipulation). The library automatically handles infrastructure setup and provides methods for document manipulation. For complex scenarios, you can access the underlying DOM directly through the library.

Workflow

1. MANDATORY - READ ENTIRE FILE: Read ooxml.md (~600 lines) completely from start to finish. NEVER set any range limits when reading this file. Read the full file content for the Document library API and XML patterns for directly editing document files.
2. Unpack the document: python ooxml/scripts/unpack.py <office_file> <output_directory>
3. Create and run a Python script using the Document library (see "Document Library" section in ooxml.md)
4. Pack the final document: python ooxml/scripts/pack.py <input_directory> <office_file>

The Document library provides both high-level methods for common operations and direct DOM access for complex scenarios.

Redlining workflow for document review

This workflow allows you to plan comprehensive tracked changes using markdown before implementing them in OOXML. CRITICAL: For complete tracked changes, you must implement ALL changes systematically.

Batching Strategy: Group related changes into batches of 3-10 changes. This makes debugging manageable while maintaining efficiency. Test each batch before moving to the next.

Principle: Minimal, Precise Edits When implementing tracked changes, only mark text that actually changes. Repeating unchanged text makes edits harder to review and appears unprofessional. Break replacements into: [unchanged text] + [deletion] + [insertion] + [unchanged text]. Preserve the original run's RSID for unchanged text by extracting the <w:r> element from the original and reusing it.

Example - Changing "30 days" to "60 days" in a sentence:

python
# BAD - Replaces entire sentence
'<w:del><w:r><w:delText>The term is 30 days.</w:delText></w:r></w:del><w:ins><w:r><w:t>The term is 60 days.</w:t></w:r></w:ins>'

# GOOD - Only marks what changed, preserves original <w:r> for unchanged text
'<w:r w:rsidR="00AB12CD"><w:t>The term is </w:t></w:r><w:del><w:r><w:delText>30</w:delText></w:r></w:del><w:ins><w:r><w:t>60</w:t></w:r></w:ins><w:r w:rsidR="00AB12CD"><w:t> days.</w:t></w:r>'

Tracked changes workflow

1. Get markdown representation: Convert document to markdown with tracked changes preserved:

   bash
   pandoc --track-changes=all path-to-file.docx -o current.md

2. Identify and group changes: Review the document and identify ALL changes needed, organizing them into logical batches:

   Location methods (for finding changes in XML):

   • Section/heading numbers (e.g., "Section 3.2", "Article IV")
   • Paragraph identifiers if numbered
   • Grep patterns with unique surrounding text
   • Document structure (e.g., "first paragraph", "signature block")
   • DO NOT use markdown line numbers - they don't map to XML structure

   Batch organization (group 3-10 related changes per batch):

   • By section: "Batch 1: Section 2 amendments", "Batch 2: Section 5 updates"
   • By type: "Batch 1: Date corrections", "Batch 2: Party name changes"
   • By complexity: Start with simple text replacements, then tackle complex structural changes
   • Sequential: "Batch 1: Pages 1-3", "Batch 2: Pages 4-6"

3. Read documentation and unpack:

   • MANDATORY - READ ENTIRE FILE: Read ooxml.md (~600 lines) completely from start to finish. NEVER set any range limits when reading this file. Pay special attention to the "Document Library" and "Tracked Change Patterns" sections.
   • Unpack the document: python ooxml/scripts/unpack.py <file.docx> <dir>
   • Note the suggested RSID: The unpack script will suggest an RSID to use for your tracked changes. Copy this RSID for use in step 4b.

4. Implement changes in batches: Group changes logically (by section, by type, or by proximity) and implement them together in a single script. This approach:

   • Makes debugging easier (smaller batch = easier to isolate errors)
   • Allows incremental progress
   • Maintains efficiency (batch size of 3-10 changes works well)

   Suggested batch groupings:

   • By document section (e.g., "Section 3 changes", "Definitions", "Termination clause")
   • By change type (e.g., "Date changes", "Party name updates", "Legal term replacements")
   • By proximity (e.g., "Changes on pages 1-3", "Changes in first half of document")

   For each batch of related changes:

   a. Map text to XML: Grep for text in word/document.xml to verify how text is split across <w:r> elements.

   b. Create and run script: Use get_node to find nodes, implement changes, then doc.save(). See "Document Library" section in ooxml.md for patterns.

   Note: Always grep word/document.xml immediately before writing a script to get current line numbers and verify text content. Line numbers change after each script run.

5. Pack the document: After all batches are complete, convert the unpacked directory back to .docx:

   bash
   python ooxml/scripts/pack.py unpacked reviewed-document.docx

6. Final verification: Do a comprehensive check of the complete document:

   • Convert final document to markdown:

     bash
     pandoc --track-changes=all reviewed-document.docx -o verification.md

   • Verify ALL changes were applied correctly:

     bash
     grep "original phrase" verification.md  # Should NOT find it
     grep "replacement phrase" verification.md  # Should find it

   • Check that no unintended changes were introduced

Converting Documents to Images

To visually analyze Word documents, convert them to images using a two-step process:

1. Convert DOCX to PDF:

   bash
   soffice --headless --convert-to pdf document.docx

2. Convert PDF pages to JPEG images:

   bash
   pdftoppm -jpeg -r 150 document.pdf page

   This creates files like page-1.jpg, page-2.jpg, etc.

Options:

• -r 150: Sets resolution to 150 DPI (adjust for quality/size balance)
• -jpeg: Output JPEG format (use -png for PNG if preferred)
• -f N: First page to convert (e.g., -f 2 starts from page 2)
• -l N: Last page to convert (e.g., -l 5 stops at page 5)
• page: Prefix for output files

Example for specific range:

bash
pdftoppm -jpeg -r 150 -f 2 -l 5 document.pdf page  # Converts only pages 2-5

Code Style Guidelines

IMPORTANT: When generating code for DOCX operations:

• Write concise code
• Avoid verbose variable names and redundant operations
• Avoid unnecessary print statements

Dependencies

Required dependencies (install if not available):

• pandoc: sudo apt-get install pandoc (for text extraction)
• docx: npm install -g docx (for creating new documents)
• LibreOffice: sudo apt-get install libreoffice (for PDF conversion)
• Poppler: sudo apt-get install poppler-utils (for pdftoppm to convert PDF to images)
• defusedxml: pip install defusedxml (for secure XML parsing)

**강점 포인트**: 작업 유형에 따라 Claude를 올바른 워크플로로 라우팅하는 명확한 결정 트리를 제공하고, 필요한 경우에만 상세 구현 파일을 참조하는 점진적 공개(progressive disclosure)를 활용해 메인 파일을 슬림하게 유지합니다. 또한 추적 변경(tracked changes) 같은 복잡한 패턴을 정확히 구현하는 방법을 good/bad 예시로 구체적으로 보여줍니다.

### 스킬 예시 #2: [브랜드 가이드라인](https://github.com/anthropics/skills/blob/main/brand-guidelines/SKILL.md?plain=1)

```markdown
#name: brand-guidelines
description: Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
license: Complete terms in LICENSE.txt
---

# Anthropic Brand Styling

## Overview

To access Anthropic's official brand identity and style resources, use this skill.

**Keywords**: branding, corporate identity, visual identity, post-processing, styling, brand colors, typography, Anthropic brand, visual formatting, visual design

## Brand Guidelines

### Colors

**Main Colors:**

- Dark: `#141413` - Primary text and dark backgrounds
- Light: `#faf9f5` - Light backgrounds and text on dark
- Mid Gray: `#b0aea5` - Secondary elements
- Light Gray: `#e8e6dc` - Subtle backgrounds

**Accent Colors:**

- Orange: `#d97757` - Primary accent
- Blue: `#6a9bcc` - Secondary accent
- Green: `#788c5d` - Tertiary accent

### Typography

- **Headings**: Poppins (with Arial fallback)
- **Body Text**: Lora (with Georgia fallback)
- **Note**: Fonts should be pre-installed in your environment for best results

## Features

### Smart Font Application

- Applies Poppins font to headings (24pt and larger)
- Applies Lora font to body text
- Automatically falls back to Arial/Georgia if custom fonts unavailable
- Preserves readability across all systems

### Text Styling

- Headings (24pt+): Poppins font
- Body text: Lora font
- Smart color selection based on background
- Preserves text hierarchy and formatting

### Shape and Accent Colors

- Non-text shapes use accent colors
- Cycles through orange, blue, and green accents
- Maintains visual interest while staying on-brand

## Technical Details

### Font Management

- Uses system-installed Poppins and Lora fonts when available
- Provides automatic fallback to Arial (headings) and Georgia (body)
- No font installation required - works with existing system fonts
- For best results, pre-install Poppins and Lora fonts in your environment

### Color Application

- Uses RGB color values for precise brand matching
- Applied via python-pptx's RGBColor class
- Maintains color fidelity across different systems

강점 포인트: Claude가 본래 알고 있지 못한 정확하고 실행 가능한 정보(헥스 코드, 폰트명, 크기 임계값) 를 제공하면서, 스킬이 무엇을 하고 언제 트리거되어야 하는지를 description으로 분명히 전달합니다.

스킬 예시 #3: 프론트엔드 디자인 스킬

markdown
name: frontend-design
description: Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.
license: Complete terms in LICENSE.txt
---

This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.

The user provides frontend requirements: a component, page, application, or interface to build. They may include context about the purpose, audience, or technical constraints.

## Design Thinking

Before coding, understand the context and commit to a BOLD aesthetic direction:
- **Purpose**: What problem does this interface solve? Who uses it?
- **Tone**: Pick an extreme: brutally minimal, maximalist chaos, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel, industrial/utilitarian, etc. There are so many flavors to choose from. Use these for inspiration but design one that is true to the aesthetic direction.
- **Constraints**: Technical requirements (framework, performance, accessibility).
- **Differentiation**: What makes this UNFORGETTABLE? What's the one thing someone will remember?

**CRITICAL**: Choose a clear conceptual direction and execute it with precision. Bold maximalism and refined minimalism both work - the key is intentionality, not intensity.

Then implement working code (HTML/CSS/JS, React, Vue, etc.) that is:
- Production-grade and functional
- Visually striking and memorable
- Cohesive with a clear aesthetic point-of-view
- Meticulously refined in every detail

## Frontend Aesthetics Guidelines

Focus on:
- **Typography**: Choose fonts that are beautiful, unique, and interesting. Avoid generic fonts like Arial and Inter; opt instead for distinctive choices that elevate the frontend's aesthetics; unexpected, characterful font choices. Pair a distinctive display font with a refined body font.
- **Color & Theme**: Commit to a cohesive aesthetic. Use CSS variables for consistency. Dominant colors with sharp accents outperform timid, evenly-distributed palettes.
- **Motion**: Use animations for effects and micro-interactions. Prioritize CSS-only solutions for HTML. Use Motion library for React when available. Focus on high-impact moments: one well-orchestrated page load with staggered reveals (animation-delay) creates more delight than scattered micro-interactions. Use scroll-triggering and hover states that surprise.
- **Spatial Composition**: Unexpected layouts. Asymmetry. Overlap. Diagonal flow. Grid-breaking elements. Generous negative space OR controlled density.
- **Backgrounds & Visual Details**: Create atmosphere and depth rather than defaulting to solid colors. Add contextual effects and textures that match the overall aesthetic. Apply creative forms like gradient meshes, noise textures, geometric patterns, layered transparencies, dramatic shadows, decorative borders, custom cursors, and grain overlays.

NEVER use generic AI-generated aesthetics like overused font families (Inter, Roboto, Arial, system fonts), cliched color schemes (particularly purple gradients on white backgrounds), predictable layouts and component patterns, and cookie-cutter design that lacks context-specific character.

Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices (Space Grotesk, for example) across generations.

**IMPORTANT**: Match implementation complexity to the aesthetic vision. Maximalist designs need elaborate code with extensive animations and effects. Minimalist or refined designs need restraint, precision, and careful attention to spacing, typography, and subtle details. Elegance comes from executing the vision well.

Remember: Claude is capable of extraordinary creative work. Don't hold back, show what can truly be created when thinking outside the box and committing fully to a distinctive vision.

강점 포인트: 높은 창의성 요구를 구체적 지침으로 구조화하고, 경계를 분명히 하며, 품질 기준을 포함해 결과물을 일정 수준 이상으로 끌어올립니다.

자주 묻는 질문

description이 실제로 트리거되게 하려면 어떻게 쓰나요?

일반적인 키워드보다 역량과 시나리오에 집중하세요. 동작 동사, 특정 파일 유형, 명확한 사용 사례를 포함합니다. “문서 처리 스킬” 대신 “PDF에서 표를 추출해 데이터 분석 워크플로를 위해 CSV로 변환”처럼 쓰세요.

Claude는 어떤 스킬을 호출할지 어떻게 결정하나요?

Claude는 의미 기반 이해로 요청과 스킬 description을 비교해 관련성을 평가합니다. 키워드 매칭이 아니라 맥락적 관련성을 판단합니다. 요청의 서로 다른 측면을 다룬다면 여러 스킬이 함께 활성화될 수 있습니다.

description의 적절한 세분화 수준은 어느 정도인가요?

단일 목적 스킬을 목표로 하세요. “블로그 글 SEO 최적화”는 재사용할 만큼 넓고, 구체적인 지침을 제공할 만큼 좁습니다.

• 너무 넓음: “콘텐츠 마케팅 도우미”
• 너무 좁음: “메타 디스크립션 추가”

조직 내에서 스킬을 어떻게 공유하나요?

팀 규모와 무관하게, 스킬 명세를 모아두는 공유 문서 리포지토리를 만드는 것을 권장합니다.

• 소규모 팀: 이름, description, 지침, 버전 정보를 담는 템플릿 형태로 관리
• 중~대규모 팀: 스킬 거버넌스 프로세스 구축

예:

• 도메인별(재무/법무/마케팅) 스킬 오너 지정
• 중앙 위키나 공유 드라이브에 스킬 라이브러리 유지
• 각 스킬의 사용 예시와 일반적인 트러블슈팅 포함
• 변경 로그로 버전 관리
• 분기별 리뷰로 업데이트 또는 폐기

모든 팀에 공통인 모범 사례:

• 각 스킬의 비즈니스 목적 문서화
• 유지보수와 업데이트를 위한 명확한 오너십 부여
• 신규 팀원이 공유 스킬을 적용하는 방법을 설명하는 온보딩 자료 제작
• 어떤 스킬이 가장 큰 가치를 내는지 추적해 유지보수 우선순위 결정
• 찾기 쉽도록 일관된 네이밍 규칙 사용

엔터프라이즈 고객은 Anthropic의 고객 성공 팀과 함께 추가 배포 옵션 및 거버넌스 프레임워크를 논의할 수 있습니다.

스킬을 어떻게 디버깅하나요?

트리거링과 실행을 분리해 테스트하세요. 스킬이 활성화되지 않으면 description을 넓히고 사용 사례를 추가합니다. 결과가 일관되지 않으면 지침을 더 구체화하고 검증 단계를 포함하세요. 정상/엣지/범위 밖 요청을 포함하는 테스트 케이스 라이브러리를 만드세요.

조직 내에서 스킬을 어떻게 공유하나요? (추가)

Claude.ai에서 스킬은 현재 사용자 개인 단위이지만, 조직 전체 관리/공유 기능이 곧 제공될 예정입니다. 그 전까지는 팀 규모와 상관없이 스킬 명세를 위한 공유 리포지토리를 만드는 것을 권장합니다. 이는 향후 기능을 대비하면서 지금부터 좋은 거버넌스를 구축하는 데 도움이 됩니다.

시작하기

스킬로 빌드할 준비가 되셨나요? 시작 방법은 다음과 같습니다.

Claude.ai 사용자:

• Settings → Features에서 Skills 활성화
• claude.ai/projects에서 첫 프로젝트 생성
• 다음 분석 작업에서 프로젝트 지식과 스킬을 결합해 보기

API 개발자:

• 문서에서 Skills 엔드포인트 탐색
• skills cookbook 확인

Claude Code 사용자:

• 플러그인 마켓플레이스로 Skills 설치
• skills cookbook 확인