Warp 를 이용하여 클로드코드 실행 - ai 기반 터미널 어플리케이션
skill-creator (https://claude.ai/settings/capabilities)
https://github.com/anthropics/skills
claude code 에서 설치하기
/plugin -> marketplace, add marketplace / anthropcis/skills 입력, example-skills, /exit
/skills
> skill-creator 스킬을 활용하여 README.md 문서를 작성하는 스킬을 생성해줘
claude-plugins-official
병렬 리서치 - 서브에이전트를 병렬로 활용
순수 HTML, CSS, JavaScript 만으로 웹 기반 슬라이드 프레젠테이션을 구현하는 최적의 방법을 리서치하세요. 외부 라이브러리(Reveal.js 등)는 참고만 하고, 최종 구현은 순수 바닐라로 가능해야 합니다.
다음 4개의 주제를 서브에이전트로 병렬 리서치하세요.
1. 슬라이드 레이아웃 & DOM 구조
2. 키보드& 마우스 네이게이션
3. 슬라이드 전환 애니메이션
4. 슬라이드 내 콘텐츠 애니메이션
전체 글
- t/ skills 00:13:46
- claude code 테스트 분석 2026.09.02
- pole zero 2026.09.02
- 전류원 2026.09.02
- skill creator 2026.09.02
- claude code skill 2026.09.01 1
t/ skills
claude code 테스트 분석
Claude Code를 반도체 테스트 패턴(ATE 프로그램) 분석·시각화·생성에 활용하는 방법을 정리해 드릴게요. 최신 문서 기준으로 확인한 내용입니다.
1. Claude Code가 이 작업에 적합한 이유
Claude Code는 터미널(또는 VS Code, JetBrains, 데스크톱 앱)에서 실행되는 에이전틱 코딩 도구로, 파일을 직접 읽고, 편집하고, 스크립트를 실행할 수 있습니다. 반도체 테스트 패턴은 보통
- STIL, WGL, ATML, TSL2 같은 표준 포맷
- 또는 Teradyne(J750/UltraFLEX), Advantest(V93000), Keysight 등 벤더별 독자 포맷
- 혹은 사내 자체 스크립트/C/Python 기반 패턴 생성기
로 존재하는데, 이런 텍스트/바이너리 기반 파일을 파싱하는 커스텀 코드를 즉석에서 작성해 실행하고, 결과를 검증하는 루프를 Claude Code가 잘 수행합니다.
2. 워크플로우 설계
프로젝트 설정 — CLAUDE.md
프로젝트 루트에 CLAUDE.md 파일을 만들어 반도체 도메인 지식을 기록해두면, 세션마다 이를 자동으로 읽습니다.
# 테스트 패턴 분석 프로젝트
## 패턴 포맷
- 사용 포맷: STIL (IEEE 1450)
- 벡터 파일 위치: /patterns/*.stil
- 핀 매핑 정의: /config/pinmap.csv
## 분석 시 확인할 것
- 타이밍 위반 (setup/hold)
- 벡터 카운트 및 반복 구간
- 사용하지 않는 핀/신호
## 코딩 컨벤션
- 파서는 Python으로 작성, pandas로 벡터 데이터 저장
- 시각화는 matplotlib/plotly 사용
분석 단계
- "이 STIL 파일을 파싱해서 핀별 벡터 시퀀스를 표로 정리해줘" 같은 요청으로 파서를 즉석에서 작성시킬 수 있습니다.
- 대용량 패턴 파일(수만~수백만 라인)의 경우, 서브에이전트를 활용해 파일을 청크 단위로 병렬 분석하게 하면 컨텍스트 낭비 없이 처리할 수 있습니다.
- 반복되는 분석 작업(예: 매주 새 패턴 검증)은 **스킬(Skill)**로 만들어두면 재사용이 쉽습니다 — .claude/skills/ 아래에 분석 절차를 저장해두는 방식입니다.
시각화
- 타이밍 다이어그램, 벡터 파형, 핀 상태 맵 등은 Claude Code에게 Python(matplotlib/plotly) 스크립트를 작성·실행시켜 이미지나 HTML로 출력하게 하면 됩니다.
- VS Code 확장이나 데스크톱 앱을 쓰면 생성된 이미지/HTML을 바로 미리보기로 확인할 수 있어 반복 조정이 편합니다.
패턴 생성
- "이 알고리즘으로 새 벡터 시퀀스를 생성해줘" 같은 요청도 가능하지만, 생성된 패턴이 실제 ATE에서 문법적으로 유효한지는 반드시 검증 루프를 넣어야 합니다 — 예: 생성 후 자체 파서로 재검증하거나, 벤더 제공 신택스 체커를 CLI로 실행해 결과를 Claude에게 피드백하는 식.
- 이런 "생성 → 자동 검증 → 수정"을 반복시키려면 훅(Hooks)으로 파일 저장 시 자동 검증 스크립트를 트리거하게 설정하는 것도 좋습니다.
3. 실전 팁
- 탐색 → 계획 → 실행 순서를 명시적으로 요청하세요 ("먼저 패턴 구조를 파악하고 계획을 세운 뒤 진행해줘"). Plan Mode를 쓰면 파일을 수정하기 전에 계획을 검토할 수 있습니다.
- 검증 가능한 기준(예: "생성된 패턴이 원본과 벡터 수가 일치해야 함")을 프롬프트에 넣어주면 Claude가 스스로 확인하며 작업합니다.
- 사내 포맷이 독자적이라면, 샘플 파일 몇 개와 스펙 문서를 프로젝트에 포함시켜두는 것이 파서 정확도에 크게 도움이 됩니다.
혹시 사용 중인 ATE 플랫폼(Teradyne/Advantest/Keysight 등)이나 패턴 포맷(STIL/WGL/자체 포맷)을 알려주시면, 그에 맞춘 파서/시각화 예제 코드를 바로 작성해드릴 수 있습니다.반도체 테스트 패턴처럼 파일 기반 코드 작업이 많다면, 위 앱으로 로컬 파일에 직접 접근해가며 작업하는 게 훨씬 수월할 거예요.
좋은 질문이에요. 결론부터 말씀드리면 가능은 하지만 방식이 다릅니다.
ASC vs MPA의 근본적 차이
- ASC: 텍스트 기반 소스 포맷이라 Claude Code가 바로 읽고 파싱할 수 있습니다. 문법 구조가 보이니까요.
- MPA: Advantest 컴파일러가 ASC를 테스터(T2000 등) 하드웨어가 실행할 수 있는 바이너리로 컴파일한 결과물입니다. 이건 Advantest의 독자 바이너리 포맷이라 공개된 스펙 문서가 없고, 제 학습 데이터에도 MPA의 정확한 바이너리 구조(헤더, 필드 레이아웃 등)는 들어있지 않습니다. 이 부분은 솔직히 말씀드려야 할 것 같아요 — 아는 척하고 잘못된 필드 해석을 드리면 더 위험합니다.
그럼 어떻게 접근할 수 있나?
1) 가장 확실한 방법 — 벤더 제공 API/툴 활용 Advantest T2000 플랫폼에는 보통 MTX(또는 유사한) 라이브러리나 CLI 유틸리티가 있어서 MPA를 다시 텍스트로 디컴파일하거나 정보를 덤프할 수 있는 경우가 많습니다. 이런 공식 도구가 있다면:
- Claude Code가 그 CLI를 호출하는 스크립트를 작성 → 출력 텍스트를 파싱 → 분석/시각화
- 이게 가장 안전하고 정확한 경로입니다.
2) 공식 도구가 없거나 부족할 때 — ASC 대비 차분 분석(reverse engineering)
- 같은 패턴을 ASC → MPA로 컴파일한 샘플 여러 개를 준비
- ASC 내용을 조금씩 바꿔가며 MPA의 바이트가 어떻게 달라지는지 비교
- Claude Code에게 hex dump 스크립트를 작성시켜 구조적 패턴(헤더 매직넘버, 벡터 반복 인코딩 등)을 추정하게 할 수 있습니다
다만 이 방법은 추측 기반이라 완전한 정확도를 보장 못 하고, 실제 테스터에 적용하기 전 반드시 검증이 필요합니다. 분석/디버깅 용도(예: 왜 두 MPA 파일이 다른지 확인)에는 유용하지만, 이 추정 구조로 MPA를 직접 생성/수정하는 건 위험합니다.
3) 현실적인 워크플로우 추천 대부분의 실무에서는 ASC 단계에서 분석·시각화·생성을 다 끝내고, MPA는 Advantest 컴파일러(공식 도구)로만 생성하는 방식을 씁니다. 즉:
- Claude Code로 ASC 파서/분석기/생성기 구축
- 컴파일은 Advantest 공식 컴파일러(bash_tool로 CLI 호출 가능하면 그것도 자동화 가능)에 맡기고
- 컴파일 후 결과(로그, 에러, 벡터 카운트 등 텍스트 출력)를 다시 Claude Code가 파싱해서 검증
질문 하나 드릴게요 — MPA를 분석하려는 목적이 (a) 컴파일이 의도대로 됐는지 검증, (b) MPA만 있고 원본 ASC가 없는 경우 복원/역분석, (c) 순수 바이너리 구조 탐구 중 어디에 가깝나요? 목적에 따라 접근법이 많이 달라져서요.
pole zero
전자회로에서 pole과 zero는 수학적으로는 전달함수 H(s)의 분모/분자를 0으로 만드는 s값이지만, 직관적으로 이해하려면 "회로가 주파수에 어떻게 반응하는가"의 관점에서 보는 게 좋습니다.
1. 핵심 직관: "저항하는 정도"와 "밀어주는 정도"
- Pole(극점) = 신호를 감쇠시키는 지점. 그 주파수 근처에서 회로가 신호를 통과시키기 "힘들어"합니다. 커패시터/인덕터가 에너지를 저장하며 신호 변화를 지연시키는 효과라고 보면 됩니다.
- Zero(영점) = 신호를 증폭/강조시키는 지점(엄밀히는 분자를 0으로 만들어 출력이 0이 되는 지점이지만, Bode 선도에서는 이득이 올라가는 효과로 나타남).
가장 쉬운 비유: RC 저역통과 필터를 생각해보세요.
- 낮은 주파수: 커패시터가 거의 개방(open) → 신호가 그대로 통과
- 높은 주파수: 커패시터가 거의 단락(short) → 신호가 접지로 빠져나가 감쇠
이 "커패시터가 단락되기 시작하는 주파수"가 바로 pole 주파수(ωₚ = 1/RC) 입니다.
2. s-평면에서의 그림
이걸 s-평면(복소평면)에서 시각화하면 더 명확해집니다. 그려드릴게요.## 3. 그림을 읽는 법 — "거리"가 핵심
전달함수의 크기는 대략 이렇게 생각할 수 있습니다:
|H(jω)| ∝ (zero까지의 거리) / (pole까지의 거리)
- jω축을 따라 위로 올라가며(주파수를 높이며) 이동할 때, pole에 가까워지면 → 분모가 작아져서 → 이득이 뚝 떨어집니다 (감쇠)
- zero에 가까워지면 → 분자가 작아져서 → 이득이 확 올라가거나(원점 zero인 경우) 꺾임이 생깁니다
즉, 극점(pole)은 "블랙홀"처럼 그 근처 주파수를 빨아들여(감쇠시켜) 통과를 막고, 영점(zero)은 반대로 그 주파수를 밀어내며 강조한다고 생각하면 직관적입니다.
4. 회로 요소와의 대응 (감각적 매핑)
회로적 의미 pole zero
| RC 저역통과 필터 | 1/RC에서 이득이 -3dB, 이후 -20dB/decade로 감소 | (단순 RC LPF엔 없음) |
| RC 고역통과 필터 | 원점 zero + 유한 pole | s=0에 zero (DC 성분 차단) |
| 되먹임(피드백) 증폭기 | 극점 개수 = 위상 지연 증가 → 안정도 저하 가능 | 위상을 앞당겨(lead) 안정도를 개선 가능 |
| 실제 물리적 느낌 | "관성", 반응이 느려지는 지점 | "가속", 반응을 앞당기는 지점 |
5. 시간 영역에서의 직관
- Pole은 **시간응답의 지수함수 형태(e^(-t/τ))**를 결정합니다. pole이 왼쪽으로 갈수록(σ가 더 음수) → 더 빨리 감쇠 → 회로가 더 빨리 안정됨.
- Zero는 시간응답의 미분(derivative) 성분을 더해주는 역할입니다. 그래서 zero가 있으면 신호의 변화(edge, transient)에 더 민감하게 반응하는 "오버슈트"가 생기기도 합니다.
6. 실무 감각 요약
- Pole = 저역통과 특성을 만든다 (고주파를 깎아낸다)
- Zero = 고역통과 특성 or 위상 보상을 만든다 (특정 주파수를 살리거나 위상을 앞당긴다)
- 두 개를 조합하면 대역통과, 대역저지, lead-lag 보상기 등 원하는 주파수 응답을 설계할 수 있습니다.
혹시 특정 회로(예: RC 필터, 연산증폭기 보상 회로, 스위칭 레귤레이터 안정도 등)에서의 pole-zero 배치를 구체적으로 살펴보고 싶으신가요?
전류원
전류원(Current Source)은 전압원과 달리 부하와 관계없이 일정한 전류를 흘려주는 회로입니다. 실제로는 이상적인 전류원을 직접 만들 수 없고, 트랜지스터의 특성을 이용해 근사적으로 구현합니다. 주요 구성 방법들을 정리해 드릴게요.
1. 기본 원리: 왜 전류원이 필요한가
이상적인 전류원은 출력 임피던스가 무한대여야 합니다. 부하가 바뀌어도 전류가 일정해야 하니까요. 실제 회로에서는 BJT나 MOSFET의 높은 출력 저항(rₒ)을 이용해서 이를 근사합니다.
2. BJT를 이용한 전류원
(1) 저항 바이어스 전류원 (가장 기본)
- 저항과 다이오드(또는 저항 분압)로 베이스 전압을 고정
- 이미터에 저항 Rₑ를 넣어 전류를 설정: I ≈ (V_B - V_BE) / R_E
- 온도 변화에 취약하다는 단점이 있음
(2) 커런트 미러 (Current Mirror) — 가장 널리 쓰이는 방식
Vcc
|
┌──┴──┐
| |
Q1 Q2 (베이스-베이스, 이미터-이미터 연결)
| |
Iref Iout
- 기준 전류(Iref)를 만드는 트랜지스터(Q1, 다이오드 연결)와 이를 복사하는 트랜지스터(Q2)로 구성
- Q1과 Q2의 베이스-이미터가 같은 전압을 공유하므로 V_BE가 같아지고, 트랜지스터 특성이 동일하면 Iout ≈ Iref
- 여러 개의 출력 트랜지스터를 병렬로 붙이면 여러 곳에 동일한(또는 비율이 다른) 전류를 공급 가능 (면적비로 전류비 조절)
(3) 윌슨 전류원 (Wilson Current Source)
- 커런트 미러에 트랜지스터 하나를 추가해 출력 저항을 크게 높인 구조
- 얼리 효과(Early effect)로 인한 오차를 줄여 정확도가 향상됨
(4) 캐스코드 전류원 (Cascode Current Source)
- 트랜지스터를 위아래로 쌓아(cascode) 출력 임피던스를 rₒ²gm 수준으로 크게 증가
- 아날로그 IC의 정밀 전류원에 많이 사용
3. MOSFET을 이용한 전류원
- 원리는 BJT와 동일하지만 V_GS 대신 게이트 전압으로 제어
- 포화영역(saturation region)에서 동작시켜 드레인 전류가 V_DS와 거의 무관하게 만듦
- MOSFET 커런트 미러도 IC 설계에서 매우 흔하게 사용됨
4. 정밀도를 높이는 방법
- **밴드갭 기준(Bandgap Reference)**과 결합하면 온도에 무관한 정전류 생성 가능
- 저항 대신 능동소자(전류원 자체)를 부하로 써서(active load) 이득을 높이는 데도 응용
5. 간단한 저항 기반 방법 (정밀도가 낮아도 될 때)
- 전압원에 큰 저항을 직렬로 연결하면 전류가 거의 일정해짐 (I ≈ V/R, 부하 저항이 R보다 훨씬 작을 때만 근사적으로 성립)
- 이는 진짜 전류원이 아니라 근사치이며, 정밀한 응용에는 부적합
요약: 실무에서 가장 많이 쓰이는 건 커런트 미러입니다. 간단하고, 여러 개의 동일한 전류원을 IC 안에서 쉽게 복제할 수 있기 때문입니다. 더 높은 정밀도가 필요하면 캐스코드나 윌슨 구조를 추가하는 식으로 발전시킵니다.
혹시 특정 응용(예: 오피앰프 내부 바이어스, LED 정전류 드라이버 등)을 염두에 두고 계신가요? 그에 맞춰 더 구체적으로 설명드릴 수 있어요.
skill creator
skill
claude code skill
반도체 테스트 장비의 패턴 매뉴얼을 스킬로 만드는 건 아주 좋은 활용 사례예요. 반복적으로 참조하는 명령어 문법, 패턴 포맷, 제약조건 같은 걸 매번 설명 안 해도 되니까요. 순서대로 설명드릴게요.
1. 스킬(Skill)이 뭔지 먼저
스킬은 SKILL.md라는 마크다운 파일(+ 필요하면 참고자료/스크립트) 묶음이에요. Claude Code가 작업을 시작할 때 스킬 목록의 이름+설명(description)만 먼저 보고, 관련 있어 보이면 그 스킬의 본문을 읽어서 지침을 따릅니다. 즉, "이런 상황엔 이렇게 해라"를 미리 문서화해두는 것.
2. 폴더 구조
te-pattern-manual/
├── SKILL.md # 필수: 언제/어떻게 쓸지 요약 지침
└── references/
├── pattern-syntax.md # 패턴 문법, 명령어 세트
├── timing-sets.md # 타이밍/레벨 설정 규칙
└── constraints.md # 장비별 제약사항, 금지 조합 등
- SKILL.md: 500줄 이내로 짧게. "이 장비 이름이 나오면/패턴 생성 요청이 오면 이 스킬을 써라" 같은 트리거 조건 + 핵심 워크플로우만.
- references/: 매뉴얼 원본 내용을 주제별로 쪼갠 참고 문서. SKILL.md에서 "패턴 시퀀스 문법이 궁금하면 references/pattern-syntax.md를 읽어라"처럼 안내만 해두면, 필요할 때만 로드돼서 컨텍스트를 아낍니다.
매뉴얼이 방대하면(예: 수백 페이지 PDF) 전체를 SKILL.md에 넣지 말고, 장비 모델별/기능별로 references 파일을 나누는 게 핵심이에요.
3. 만드는 절차 (Claude Code에서)
- 매뉴얼 업로드: PDF나 텍스트로 된 패턴 매뉴얼을 Claude Code 프로젝트에 올려주세요.
- 저에게 요청: "이 매뉴얼을 바탕으로 테스트 패턴 생성 스킬을 만들어줘"라고 하면 됩니다. 이때 저는:
- 매뉴얼에서 패턴 문법, 명령어, 제약조건을 추출
- SKILL.md 초안 작성 (트리거 조건, 워크플로우, 참고파일 안내)
- 방대한 부분은 references/ 파일로 분리
- 트리거 조건 명확히 하기: description에 "어떤 장비 이름/어떤 요청 문구가 나올 때 이 스킬을 써야 하는지"를 최대한 구체적이고 적극적으로 적어야 인식이 잘 됩니다. 예:"XYZ 테스터 장비의 테스트 패턴을 생성/수정할 때 사용. 'XYZ 패턴', '테스트 벡터 생성', 'STIL 파일' 등의 요청이 있으면 반드시 이 스킬을 참조."
- 테스트: 실제로 "이 핀에 대한 walking 1 패턴 만들어줘" 같은 프롬프트를 몇 개 던져서 스킬이 트리거되고 결과가 매뉴얼 규칙을 잘 따르는지 확인.
- 반복 개선: 결과가 틀리면 SKILL.md나 references를 수정 → 재테스트.
원하시면 skill-creator 스킬을 이용해서 이 과정(초안 작성 → 테스트 케이스 실행 → 평가 → 개선)을 체계적으로 진행할 수도 있어요.
4. 실제 테스트 패턴 생성에 활용하는 법
스킬이 만들어지고 나면, 이후 대화에서는 그냥 자연스럽게 요청하면 됩니다:
- "이 장비용으로 D-flip flop 스캔 테스트 패턴 만들어줘"
- "이 핀맵에 대해 march 알고리즘 기반 메모리 테스트 패턴 생성해줘, STIL 포맷으로"
그러면 저는 자동으로 스킬을 인식 → references의 문법/제약조건을 참조 → 매뉴얼 규격에 맞는 패턴 파일(STIL, WGL, 벤더별 포맷 등)을 생성합니다. 특히 반복적인 문법 규칙(타이밍셋 이름, 레벨 정의, 벡터 포맷)을 매번 설명 안 해도 되니 속도와 정확도가 크게 올라갑니다.
5. 시작하려면
지금 갖고 계신 패턴 매뉴얼 파일이 있으면 업로드해주세요. 업로드해주시면 바로:
- 어떤 장비/포맷인지
- 어떤 종류의 패턴을 자주 생성할지 (스캔, 메모리, 기능 테스트 등)
- 출력 포맷(STIL/WGL/벤더 전용)
skill-creator가 뭔지
skill-creator는 스킬을 "만들어주는" 메타 스킬이에요. 제가 방금 설명드린 것처럼 스킬을 손으로 하나하나 설계하는 대신, skill-creator를 쓰면 이 과정을 체계적으로 도와줍니다:
- 의도 파악: 어떤 작업을 시킬 건지, 언제 트리거돼야 하는지, 출력 포맷은 뭔지 인터뷰
- 초안 작성: SKILL.md 초안 + 필요하면 references/scripts/assets 구조 생성
- 테스트 케이스 실행: 실제 프롬프트 몇 개로 스킬이 잘 작동하는지 시험
- 평가: 결과를 사람이 보기 좋게 정리해서(eval-viewer) 리뷰
- 트리거 정확도 최적화: description 문구를 자동으로 여러 버전 만들어서 어떤 게 스킬을 제일 잘 트리거하는지 벤치마크 (run_loop.py)
- 패키징: 완성된 스킬을 .skill 파일로 묶어서 전달
즉, "스킬을 잘 만들도록 도와주는 컨설턴트+테스트 자동화 도구" 같은 존재예요. 반도체 패턴 매뉴얼 스킬처럼 정답이 명확한(문법/제약조건이 맞았는지 검증 가능한) 케이스에는 특히 유용합니다 — 실제로 생성된 패턴이 매뉴얼 규칙을 지켰는지 정량적으로 체크할 수 있거든요.
스킬이 RAG처럼 동작하나?
비슷한 목적(관련 정보를 필요할 때 가져온다)을 갖고 있지만, 메커니즘은 달라요.
RAG 스킬
| 검색 방식 | 쿼리를 임베딩해서 벡터 DB에서 유사도 검색 | Claude가 스킬 목록의 name+description을 보고 "이거 관련 있네" 판단 |
| 로딩 단위 | 청크(chunk) 단위로 조각조각 검색 | 파일 단위로 통째로 로드 (SKILL.md 본문 → 필요시 references 파일) |
| 정확도 근거 | 임베딩 유사도(근사치) | Claude의 판단(추론) — 더 유연하지만 덜 결정론적 |
| 구조 | 자동 인덱싱, 사람이 문서를 미리 구조화할 필요 적음 | 사람이 SKILL.md와 references를 의도적으로 설계 |
핵심 차이는 "3단계 점진적 공개(progressive disclosure)" 구조예요:
- 1단계: 스킬 이름+description만 항상 컨텍스트에 있음 (가벼움)
- 2단계: 스킬이 트리거되면 SKILL.md 본문이 로드됨
- 3단계: SKILL.md가 "이 상황이면 references/xxx.md를 읽어라"라고 안내하면, 그때만 해당 파일을 로드
이건 RAG의 "관련 정보만 끌어온다"는 목표와 비슷하지만, 검색이 벡터 유사도가 아니라 Claude가 직접 읽고 판단해서 필요한 파일을 고르는 방식이라는 점이 달라요. 그래서 매뉴얼처럼 구조가 명확한 문서(장비별/기능별로 나뉘는)에는 RAG보다 스킬 쪽이 더 예측 가능하고 정확할 때가 많습니다 — 다만 매뉴얼이 수천 페이지급으로 매우 방대하고 검색 대상이 애매한 자연어 질의라면 RAG(임베딩 검색)이 더 적합할 수도 있어요.
반도체 패턴 매뉴얼처럼 "장비 모델별/명령어별로 구조화 가능한" 문서는 스킬 방식이 잘 맞습니다.
두 군데 다 가능하고, 용도에 따라 다릅니다.
위치 두 가지
개인 스킬 (Personal skill): ~/.claude/skills/
- 홈 디렉토리에 위치, 어떤 프로젝트를 열든 항상 사용 가능
- 반도체 패턴 매뉴얼처럼 "여러 프로젝트에서 계속 쓸 나만의 지식"이라면 여기가 적합
프로젝트 스킬 (Project skill): 프로젝트루트/.claude/skills/
- 해당 저장소(repo)에서만 활성화
- git으로 커밋하면 팀원들과 함께 공유됨 — 회사 팀 전체가 같은 매뉴얼 스킬을 쓰게 하고 싶다면 이쪽
이름이 같은 스킬이 두 군데 다 있으면 프로젝트 스킬이 개인 스킬보다 우선합니다(더 구체적인 컨텍스트로 간주).
만드는 법 (수동으로)
# 개인 스킬로 만들 경우
mkdir -p ~/.claude/skills/te-pattern-manual
# SKILL.md 작성...
# 프로젝트 스킬로 만들 경우
mkdir -p .claude/skills/te-pattern-manual
저에게 "이 매뉴얼로 스킬 만들어줘"라고 하면 제가 알아서 파일을 만들어드리는데, 그때 개인용/프로젝트용 중 어디에 만들지 여쭤보고 진행할게요.
인식·사용 방식
- Claude Code 세션이 시작될 때 두 디렉토리(~/.claude/skills/, .claude/skills/)를 스캔해서 각 스킬의 이름 + description만 가볍게 컨텍스트에 올려둡니다. (본문 전체를 다 읽는 게 아니라 "이런 스킬이 있다"는 목록만)
- 대화 중 제가 사용자의 요청을 보고 "이 상황은 저 스킬의 description과 맞아떨어지네"라고 판단하면, 그때 그 스킬의 SKILL.md 본문을 컨텍스트에 불러옵니다.
- SKILL.md 본문이 "패턴 문법 자세한 건 references/pattern-syntax.md 참고"라고 안내하면, 필요할 때만 그 파일도 추가로 읽습니다.
그래서 별도로 /스킬이름처럼 직접 호출할 필요 없이, "이 장비용 스캔 패턴 만들어줘"라고만 해도 자동으로 트리거됩니다 — description을 얼마나 명확하게 썼는지가 인식률을 좌우해요.
파일이 수정되면 Claude Code가 변경을 감지해서 다시 읽어들이므로, 세션 중간에 SKILL.md를 고쳐도 재시작 없이 반영됩니다. 다만 프로젝트 스킬 폴더(.claude/skills/)를 처음 만드는 경우엔 워크스페이스 신뢰(trust) 승인이 한 번 필요할 수 있어요Claude Code는 스킬 디렉토리의 파일 변경을 감시하며, 프로젝트의 .claude/skills/의 경우 워크스페이스 신뢰 대화상자를 먼저 수락해야 합니다.
정리: 회사/팀 공용 매뉴얼이라 여러 명이 같이 쓸 거면 → 프로젝트 스킬 + git 커밋. 본인만 여러 프로젝트에서 계속 쓸 개인 도구라면 → 개인 스킬(~/.claude/skills/)이 편합니다.
스킬 참고
(바이브 코딩 예제 모음) https://wikidocs.net/343999
(클로드 스킬 이해, 갓대희 작은공간) https://goddaehee.tistory.com/440 https://goddaehee.tistory.com/411