Claude Code 커스텀 스킬 작성

Published: at 10:50 PM

들어가며

24차시에서는 Skills의 개념과 호출 방식을 다뤘다. on-demand 로드, 3단계 progressive disclosure, 4계층 위치, 자동/수동 호출 제어까지 — Skills가 무엇인지와 이미 있는 스킬을 어떻게 부르는지였다.

이번 차시는 그 다음이다. 직접 쓴다. 빈 디렉토리에서 시작해 동작하는 스킬을 만들어내는 과정을 본다.

스킬을 처음 쓰면 SKILL.md 한 줄짜리 description과 다섯 줄짜리 본문으로도 동작한다. 그래서 만들기는 쉽다. 어려운 건 잘 쓰는 것이다 — Claude가 적절한 타이밍에 자동 호출하고, 본문이 컨텍스트를 헛되이 잡아먹지 않으며, 작업이 안정적으로 재현되게 하는 것.

이번 차시는 그 격차를 다룬다.

26차시에서는 PR 리뷰, 테스트 생성, 문서화 같은 실전 스킬 예제를, 27차시에서는 context: fork를 쓴 서브에이전트 스킬을 다룬다.

디렉토리 구조

스킬은 디렉토리다. 안에 SKILL.md가 들어 있고, 나머지는 모두 선택이다.

my-skill/
├── SKILL.md          # 필수 — 진입점 (frontmatter + 본문)
├── scripts/          # 선택 — 실행 가능한 코드
├── references/       # 선택 — 디테일 레퍼런스 문서
├── assets/           # 선택 — 템플릿, 데이터, 이미지
└── ...

세 디렉토리는 Agent Skills 표준이 권장하는 컨벤션이다. 각자 역할이 다르다.

핵심: supporting files는 SKILL.md에서 명시적으로 언급해야 Claude가 알 수 있다. 디렉토리에 파일을 넣어두기만 하면 모른 채로 지나간다.

SKILL.md 구조

SKILL.md는 두 부분이다 — YAML frontmatter와 마크다운 본문.

---
name: my-skill
description: A description of what this skill does and when to use it.
---

Your skill instructions here...

name 제약

name 필드는 표준이 강제하는 규칙이 있다.

# 유효
name: pdf-processing
name: data-analysis
name: code-review

# 무효
name: PDF-Processing  # 대문자 안 됨
name: -pdf            # 시작 하이픈 안 됨
name: pdf--processing # 연속 하이픈 안 됨

Claude Code에서는 name을 생략하면 디렉토리 이름이 쓰이므로 사실상 디렉토리 이름이 슬래시 명령 이름이 된다.

description 제약

description은 표준이 1–1024자로 정한다. Claude Code는 description+when_to_use 합산을 1,536자에서 truncate한다 — 길게 쓰면 잘린다.

description의 무게는 다른 곳에 있다. 이게 트리거의 거의 전부다. 사용자가 /로 직접 호출하지 않으면 Claude는 description만 보고 이 스킬을 쓸지 말지 결정한다. 본문이 아무리 좋아도 description이 약하면 자동 호출이 안 된다.

이 점은 뒤의 “description 최적화”에서 본격적으로 다룬다.

표준 frontmatter 필드

필드필수제약
name필수디렉토리 이름과 일치, 64자
description필수1024자
license선택라이선스 이름 또는 파일 참조
compatibility선택환경 요구사항. 500자
metadata선택임의 key-value
allowed-tools선택자동 승인 도구 (실험적)

대부분 스킬은 name과 description만 쓴다. compatibility는 특정 환경(예: “Requires Python 3.14+ and uv”)이 필요할 때만 추가한다.

Claude Code 확장 필드

24차시에서 본 필드들이 그대로 쓰인다.

필드용도
when_to_usedescription 보충 (트리거 문구, 예시 요청)
argument-hint자동완성 힌트. [issue-number]
argumentsnamed positional arguments ($name 치환)
disable-model-invocationtrue이면 사용자만 호출
user-invocablefalse이면 Claude만 호출
allowed-tools스킬 동안 자동 승인되는 도구
model스킬 동안 모델 override
effort스킬 동안 effort 레벨 override
contextfork로 격리 서브에이전트 실행
agentcontext: fork일 때 어떤 서브에이전트
hooks스킬 lifecycle 한정 hook
paths글롭 패턴 — 매칭 파일 작업 시에만 활성화
shellbash (기본) 또는 powershell

Agent Skills 표준에는 name, description, license, compatibility, metadata, allowed-tools만 있다. 나머지는 Claude Code 확장이라 다른 도구(Cursor, OpenCode 등)에서는 무시된다.

두 종류의 콘텐츠

스킬을 쓰기 전에 이게 어떤 종류인지 정해야 한다. Claude Code 공식 문서는 두 가지로 나눈다.

Reference content (참조 자료)

Claude가 현재 작업에 적용할 지식이다. 컨벤션, 패턴, 스타일 가이드, 도메인 지식. 호출되면 본문이 inline으로 컨텍스트에 흐르고, Claude는 다른 작업을 하면서 이 지식을 같이 적용한다.

---
name: api-conventions
description: API design patterns for this codebase
---

When writing API endpoints:
- Use RESTful naming conventions
- Return consistent error formats
- Include request validation

자동 호출에 적합하다. “API endpoint 작성해줘” 같은 요청에 Claude가 알아서 가져와서 적용한다.

Task content (작업 자료)

특정 액션의 단계별 지시다. 배포, 커밋, 코드 생성. 보통 사용자가 /skill-name으로 직접 호출한다 — Claude가 멋대로 트리거하지 않게 disable-model-invocation: true를 붙이는 게 보통이다.

---
name: deploy
description: Deploy the application to production
context: fork
disable-model-invocation: true
---

Deploy the application:
1. Run the test suite
2. Build the application
3. Push to the deployment target

작업이 사이드 이펙트를 가지면 (배포, 커밋, Slack 발송) disable-model-invocation: true가 안전하다. Claude가 “코드가 좋아 보여” 하고 deploy를 트리거하는 걸 막는다.

내가 만들 스킬이 어느 쪽인가? 같이 흐르는 지식인가, 호출되는 액션인가? 결정한 다음 frontmatter와 본문을 그에 맞춰 쓴다.

작성 프로세스

처음부터 좋은 스킬은 안 나온다. 첫 draft는 거의 항상 다듬어야 한다. 공식 문서가 권하는 프로세스가 있다.

1. 실제 expertise에서 시작

흔한 실수: LLM에 “PDF 처리 스킬 만들어줘”라고 시킨다. 결과는 generic한 프로시저다 — “에러를 적절히 처리하라”, “인증 베스트 프랙티스를 따르라”. 도메인이 없는 LLM의 일반 지식만 흘러나온다.

좋은 스킬은 실제 expertise에 grounded되어 있다. 두 가지 경로가 있다.

A. Hands-on task에서 추출

실제 작업을 Claude와 함께 한다. 컨텍스트, corrections, preferences를 채팅 중에 제공한다. 그 다음 재사용 가능한 패턴을 스킬로 추출한다. 다음에 주목한다.

B. 기존 artifacts에서 합성

이미 도메인 지식이 글로 있다면, LLM에 합성시킨다. 단, 프로젝트 특화 자료를 먹인다 — generic “data engineering best practices”가 아니라 우리 팀의 incident report와 runbook을. 좋은 소스는 다음과 같다.

2. 실제 실행으로 refine

첫 draft를 실제 task에 돌린다. 그리고 결과를 — 실패만이 아니라 성공도 — 다시 작성에 피드백한다.

한 번의 execute-then-revise도 의미 있는 개선이고, 복잡 도메인은 여러 번 돌린다.

Tip: 에이전트의 실행 trace를 읽어라. 최종 출력만이 아니라. 에이전트가 unproductive 단계에 시간을 쓰면 보통 — instruction이 너무 vague (몇 가지 접근을 시도해야 동작), instruction이 현재 작업에 맞지 않음 (그래도 따라감), 또는 옵션이 너무 많이 제시되고 default가 없음.

컨텍스트 절약

스킬이 활성화되면 SKILL.md 본문 전체가 에이전트의 컨텍스트 윈도우에 들어간다 — 대화 히스토리, 시스템 컨텍스트, 다른 활성 스킬과 자리를 다툰다. 모든 토큰이 에이전트의 attention을 두고 경쟁한다.

에이전트가 모를 것만 추가

스킬이 없으면 에이전트가 모를 것에 집중한다. 프로젝트 컨벤션, 도메인별 절차, 비자명한 엣지 케이스, 특정 도구나 API. PDF가 무엇인지, HTTP가 어떻게 동작하는지, DB 마이그레이션이 무엇인지는 설명할 필요가 없다.

<!-- 너무 verbose — 에이전트가 PDF가 뭔지 이미 안다 -->
## 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. pdfplumber is recommended because it handles most cases well.
<!-- Better — 에이전트가 모를 부분으로 직진 -->
## Extract PDF text

Use pdfplumber for text extraction. For scanned documents, fall back to
pdf2image with pytesseract.

각 콘텐츠 조각에 대해 묻는다 — “이 instruction 없으면 에이전트가 틀릴까?” 답이 No면 cut. 확신이 없으면 테스트한다. 그리고 스킬 없이도 에이전트가 task를 잘 처리한다면 — 그 스킬은 가치를 더하지 않는다.

Coherent unit 디자인

스킬의 범위는 함수의 범위와 같은 결정이다. 한 coherent unit을 캡슐화하고, 다른 스킬과 잘 조합되어야 한다.

예: “DB 쿼리 + 결과 포매팅”은 한 coherent unit. 거기에 “DB 어드민”까지 넣으면 너무 넓다.

Moderate detail

엄청 포괄적인 스킬은 도움보다 해가 되기도 한다 — 에이전트가 무엇이 relevant인지 못 뽑아내고, 현재 작업에 안 맞는 instruction에 따라 unproductive 경로를 탄다.

간결한 stepwise 가이드 + 작동하는 예시가 exhaustive 문서를 이긴다. 모든 엣지 케이스를 다루는 자신을 발견하면, 대부분은 에이전트의 judgment에 맡기는 게 낫지 않은지 묻는다.

Progressive disclosure로 큰 스킬 분할

표준 권장은 SKILL.md를 500줄, 5,000 토큰 이하로 두는 것이다. 디테일은 references/로 분리한다.

핵심은 언제 그 파일을 로드할지 에이전트에게 알려주는 것이다.

For complete API error reference, see [references/api-errors.md](references/api-errors.md)
when the API returns a non-200 status code.

generic “see references/ for details” 보다 명시적인 트리거가 효과적이다. 그래야 progressive disclosure가 의도한 대로 — on-demand 로드 — 동작한다.

Calibrating control

스킬의 모든 부분이 같은 수준의 prescriptiveness를 필요로 하지 않는다. task의 fragility에 맞춰 보정한다.

자유 vs 규정

자유 부여 — 여러 접근이 valid하고 task가 variation을 허용할 때. 왜 인지를 설명하는 게 rigid한 directives보다 효과적이다. 목적을 이해한 에이전트가 컨텍스트별 결정을 더 잘 한다.

## Code review process

1. Check all database queries for SQL injection (use parameterized queries)
2. Verify authentication checks on every endpoint
3. Look for race conditions in concurrent code paths
4. Confirm error messages don't leak internal details

Prescriptive — operations이 fragile하거나, consistency가 중요하거나, 특정 sequence가 필요할 때.

## Database migration

Run exactly this sequence:

```bash
python scripts/migrate.py --verify --backup
```

Do not modify the command or add additional flags.

대부분 스킬은 둘이 섞여 있다. 각 부분을 따로 보정한다.

기본값 제공, 메뉴 X

여러 도구나 접근이 가능할 때 기본값 하나를 고르고 alternatives는 짧게 언급한다. equal options로 늘어놓지 않는다.

<!-- 옵션 너무 많음 -->
You can use pypdf, pdfplumber, PyMuPDF, or pdf2image...
<!-- 분명한 default + escape hatch -->
Use pdfplumber for text extraction. For scanned PDFs requiring OCR,
use pdf2image with pytesseract instead.

Procedures, not declarations

스킬은 한 클래스의 문제를 어떻게 접근할지 가르쳐야 한다. 한 인스턴스에 대해 무엇을 생산할지가 아니라.

<!-- 특정 답 — 이 정확한 task에만 유용 -->
Join the `orders` table to `customers` on `customer_id`, filter where
`region = 'EMEA'`, and sum the `amount` column.
<!-- 재사용 가능한 method — 임의의 분석 쿼리에 동작 -->
1. Read the schema from `references/schema.yaml` to find relevant tables
2. Join tables using the `_id` foreign key convention
3. Apply any filters from the user's request as WHERE clauses
4. Aggregate numeric columns as needed and format as a markdown table

스킬에 specific한 디테일이 들어가면 안 된다는 뜻은 아니다 — 출력 형식 템플릿, “PII는 절대 출력 금지” 같은 제약, 도구별 instructions는 모두 valuable하다. 핵심은 접근은 generalize되어야 한다는 것이다.

본문 패턴

다음 패턴들은 잘 동작하는 스킬에서 반복적으로 나타난다. 모든 스킬이 다 가져야 하는 건 아니고, task에 맞는 것을 선택한다.

Gotchas 섹션

가장 가치 있는 콘텐츠는 종종 gotchas 리스트 — 합리적인 추론으로는 못 잡는 환경별 사실들이다. 일반 조언(“에러를 적절히 처리하라”)이 아니라, 에이전트가 모르면 반드시 틀릴 구체적 corrections.

## Gotchas

- The `users` table uses soft deletes. Queries must include
  `WHERE deleted_at IS NULL` or results will include deactivated accounts.
- The user ID is `user_id` in the database, `uid` in the auth service,
  and `accountId` in the billing API. All three refer to the same value.
- The `/health` endpoint returns 200 as long as the web server is running,
  even if the database connection is down. Use `/ready` to check full
  service health.

gotchas는 SKILL.md 본문에 둔다. 별도 reference로 빼면 에이전트가 “지금 그 reference를 봐야 한다”고 인식 못 할 수 있다 — 비자명한 이슈는 트리거가 명확치 않다.

Tip: 에이전트의 실수를 수정해주는 일이 생기면, 그 수정을 gotchas 섹션에 추가한다. 가장 직접적인 iterative 개선 방법이다.

출력 형식 템플릿

특정 형식의 산출물이 필요하면 템플릿을 제공한다. 형식을 prose로 묘사하는 것보다 신뢰할 만하다 — 에이전트는 구체적 구조에 패턴 매칭을 잘한다. 짧은 템플릿은 SKILL.md에 inline, 긴 템플릿이나 가끔만 필요한 템플릿은 assets/에.

## Report structure

Use this template:

```markdown
# [Analysis Title]

## Executive summary
[One-paragraph overview of key findings]

## Key findings
- Finding 1 with supporting data
- Finding 2 with supporting data

## Recommendations
1. Specific actionable recommendation
2. Specific actionable recommendation
```

멀티스텝 체크리스트

의존성이나 검증 게이트가 있는 workflow에서 progress를 명시한 체크리스트가 도움이 된다.

## Form processing workflow

Progress:
- [ ] Step 1: Analyze the form (run `scripts/analyze_form.py`)
- [ ] Step 2: Create field mapping (edit `fields.json`)
- [ ] Step 3: Validate mapping (run `scripts/validate_fields.py`)
- [ ] Step 4: Fill the form (run `scripts/fill_form.py`)
- [ ] Step 5: Verify output (run `scripts/verify_output.py`)

Validation loops

작업하고, validator 돌리고, 실패면 고치고, 다시 → 통과까지. 에이전트가 자기 작업을 검증하게 만든다.

## Editing workflow

1. Make your edits
2. Run validation: `python scripts/validate.py output/`
3. If validation fails:
   - Review the error message
   - Fix the issues
   - Run validation again
4. Only proceed when validation passes

reference 문서가 “validator” 역할을 할 수도 있다 — 에이전트에게 “마치기 전에 reference에 비춰 확인하라”고 지시한다.

Plan-validate-execute

배치 작업이나 destructive 작업에서, 에이전트가 중간에 구조화된 plan을 만들고, source of truth에 비춰 검증한 뒤, 그제야 실행하게 한다.

## PDF form filling

1. Extract form fields: `python scripts/analyze_form.py input.pdf` → `form_fields.json`
   (lists every field name, type, and whether it's required)
2. Create `field_values.json` mapping each field name to its intended value
3. Validate: `python scripts/validate_fields.py form_fields.json field_values.json`
   (checks that every field name exists in the form, types are compatible, and
   required fields aren't missing)
4. If validation fails, revise `field_values.json` and re-validate
5. Fill the form: `python scripts/fill_form.py input.pdf field_values.json output.pdf`

핵심은 3단계의 validation이다. plan(field_values.json)을 source of truth(form_fields.json)에 비춘다. 명확한 에러 — Field 'signature_date' not found — available fields: customer_name, order_total, signature_date_signed — 가 에이전트의 자기 수정을 가능하게 한다.

scripts/ 디자인

스킬이 같은 로직을 매번 LLM에게 재발명시키고 있다면 — 차트 그리기, 특정 형식 파싱, 출력 검증 — 한 번 작성한 검증된 스크립트를 scripts/에 번들한다.

에이전트가 쓸 스크립트는 사람이 쓸 스크립트와 다르다. 몇 가지 디자인 결정이 차이를 만든다.

인터랙티브 프롬프트 금지

이건 하드 요구사항이다. 에이전트는 non-interactive shell에서 동작한다 — TTY 프롬프트, 패스워드 다이얼로그, confirmation 메뉴에 응답할 수 없다. 인터랙티브 입력에 블락되는 스크립트는 무한 hang.

모든 입력을 CLI 플래그, 환경 변수, 또는 stdin으로 받는다.

# Bad: 입력 기다리며 hang
$ python scripts/deploy.py
Target environment: _

# Good: 가이드 있는 명확한 에러
$ python scripts/deploy.py
Error: --env is required. Options: development, staging, production.
Usage: python scripts/deploy.py --env staging --tag v1.2.3

--help로 사용법 문서화

--help 출력은 에이전트가 스크립트의 인터페이스를 배우는 주된 경로다. 짧은 설명, 사용 가능한 플래그, 사용 예시.

Usage: scripts/process.py [OPTIONS] INPUT_FILE

Process input data and produce a summary report.

Options:
  --format FORMAT    Output format: json, csv, table (default: json)
  --output FILE      Write output to FILE instead of stdout
  --verbose          Print progress to stderr

Examples:
  scripts/process.py data.csv
  scripts/process.py --format csv --output report.csv data.csv

간결하게 — 출력은 에이전트의 컨텍스트에 다른 모든 것과 함께 들어간다.

도움 되는 에러 메시지

에이전트가 에러를 받으면 그 메시지가 다음 시도를 직접 결정한다. 불투명한 “Error: invalid input”은 한 턴을 낭비한다. 무엇이 잘못, 무엇이 기대, 무엇을 시도.

Error: --format must be one of: json, csv, table.
       Received: "xml"

구조화된 출력

JSON, CSV, TSV가 free-form text보다 좋다. 에이전트와 표준 도구(jq, cut, awk)가 둘 다 소비할 수 있어 파이프라인에서 composable해진다.

# 정렬된 공백 — 프로그래밍적으로 파싱 어려움
NAME          STATUS    CREATED
my-service    running   2025-01-15

# 구분된 — 명확한 필드 경계
{"name": "my-service", "status": "running", "created": "2025-01-15"}

데이터와 진단을 분리한다 — 구조화된 데이터는 stdout으로, 진행 메시지/경고/진단은 stderr로. 에이전트가 깨끗한 파싱 가능 출력을 잡으면서, 필요할 때 진단도 볼 수 있다.

자체 의존성 선언 스크립트

PEP 723이 Python에서 inline 의존성 선언을 표준화했다.

# /// script
# dependencies = [
#   "beautifulsoup4",
# ]
# ///

from bs4 import BeautifulSoup
# ...

uv run scripts/extract.py로 실행하면 격리 환경에서 의존성을 자동 설치하고 돈다 — 별도 manifest 파일이나 install 단계 없이.

Deno (npm: import), Bun (auto-install), Ruby (bundler/inline)에도 비슷한 메커니즘이 있다.

기타 고려사항

description 최적화

스킬이 활성화되지 않으면 본문이 아무리 좋아도 소용없다. description이 트리거의 모든 것이다.

좋은 description의 원칙

Bad vs Good

# Bad
description: Helps with PDFs.
# Bad
description: Process CSV files.
# Good
description: >
  Extracts text and tables from PDF files, fills PDF forms, and merges
  multiple PDFs. Use when working with PDF documents or when the user
  mentions PDFs, forms, or document extraction.
# Good
description: >
  Analyze CSV and tabular data files — compute summary statistics, add
  derived columns, generate charts, and clean messy data. Use this skill
  when the user has a CSV, TSV, or Excel file and wants to explore,
  transform, or visualize the data, even if they don't explicitly mention
  "CSV" or "analysis."

좋은 쪽이 무엇을 하는지에 더 specific하고 (요약 통계, derived columns, 차트, 정리), 언제 적용되는지에 더 broad하다 (CSV/TSV/Excel; “CSV”라는 단어 없어도).

트리거가 약하다는 신호

description을 손볼 신호.

너무 자주 트리거되면

체계적 평가

description이 reliable하게 트리거되는지 확인하려면 eval queries를 짠다.

skill-creator 스킬이 이 루프를 자동화한다 — eval set 분할, 병렬 trigger rate 평가, Claude로 description 개선 제안, 라이브 HTML 리포트 생성까지.

검증

스킬을 publish 전에 표준 준수를 확인하려면 skills-ref 라이브러리를 쓴다.

skills-ref validate ./my-skill

frontmatter가 유효한지, naming convention을 따르는지 체크한다.

첫 스킬: explain-code

이 모든 걸 작은 예시에 적용해 본다. 코드 설명을 시각적 다이어그램과 비유로 하는 스킬이다.

디렉토리 만들기.

mkdir -p ~/.claude/skills/explain-code

~/.claude/skills/explain-code/SKILL.md 작성.

---
description: Explains code with visual diagrams and analogies. Use when explaining how code works, teaching about a codebase, or when the user asks "how does this work?"
---

When explaining code, always include:

1. **Start with an analogy**: Compare the code to something from everyday life
2. **Draw a diagram**: Use ASCII art to show the flow, structure, or relationships
3. **Walk through the code**: Explain step-by-step what happens
4. **Highlight a gotcha**: What's a common mistake or misconception?

Keep explanations conversational. For complex concepts, use multiple analogies.

테스트.

# 자동 호출
> How does this code work?

# 직접 호출
> /explain-code src/auth/login.ts

이 스킬은 description의 핵심 사용 사례를 앞쪽에 두고 있다 — “Explains code with visual diagrams and analogies.” 그 다음 언제 쓸지가 따른다 — “Use when explaining how code works, teaching about a codebase, or when the user asks ‘how does this work?’”. 사용자가 자연스럽게 쓸 phrase(“how does this work”)가 들어 있다.

본문은 declaration이 아니라 procedure다 — 비유로 시작 → 다이어그램 → step-by-step → gotcha. specific한 결과물이 아니라 어떤 코드든 적용 가능한 method.

이 한 파일이 두 호출 경로 모두를 연다 — /explain-code로 직접 호출, 또는 “how does this work?” 같은 자연 발화로 자동 호출.

정리

핵심 요점

  1. 스킬은 디렉토리 — <name>/SKILL.md + 선택 scripts//references//assets/
  2. name 제약 — 디렉토리 이름과 일치, 소문자/숫자/하이픈만, 64자
  3. description은 트리거의 거의 전부 — 1024자 (Claude Code는 description+when_to_use 1,536자 캡)
  4. 두 종류 콘텐츠 — Reference content (지식, 자동 호출) vs Task content (액션, disable-model-invocation: true)
  5. 실제 expertise에서 시작 — generic LLM 합성이 아니라 hands-on task 추출이나 프로젝트별 artifacts 합성
  6. Execute-then-revise — 첫 draft를 실제 task에 돌리고 결과를 작성에 피드백
  7. 에이전트가 모를 것만 추가 — “이 instruction 없으면 틀릴까?” No면 cut
  8. Coherent unit — 한 작업에 여러 스킬 로드 X, 동시에 너무 넓지도 X
  9. Moderate detail — exhaustive 문서 X, 간결한 stepwise + 예시
  10. 큰 스킬은 progressive disclosure — SKILL.md 500줄/5,000 토큰 이하, 디테일은 references/로
  11. Calibrate prescriptiveness — 자유 부여 vs 규정을 task의 fragility에 맞춰 보정
  12. Defaults, not menus — 기본값 하나 + 짧은 escape hatch
  13. Procedures, not declarations — 한 클래스 문제의 접근법 (재사용), 한 인스턴스의 답 (X)
  14. 본문 패턴 — Gotchas, Templates, Checklists, Validation loops, Plan-validate-execute
  15. scripts/ 디자인 — non-interactive, --help, 도움 되는 에러, 구조화된 출력 (stdout 데이터/stderr 진단), idempotency, dry-run, exit codes
  16. PEP 723 등 inline 의존성 — uv run으로 격리 환경에서 한 줄 실행
  17. description 최적화 — 명령형, 사용자 의도 중심, pushy, 핵심을 앞쪽에
  18. eval queries로 트리거 검증 — should-trigger + near-miss should-not-trigger, 여러 번 실행, train/validation 분할
  19. skills-ref validate로 표준 준수 확인

확인해볼 링크

다음 단계

이번 차시는 “스킬을 처음부터 어떻게 짜는가”였다. 26차시에서는 PR 리뷰, 테스트 생성, 문서화 같은 실전 스킬 예제를 직접 짜본다. 27차시에서는 context: fork로 격리된 서브에이전트에서 도는 Subagent 스킬을 본격적으로 다룬다.

참고 자료

Next Post
Claude Code Skills 개념과 기본 사용