software-mansion-labs/skills. React Native 전문 회사 Software Mansion이, 자사의 프로덕션 노하우(애니메이션·제스처·Skia·온디바이스 AI·오디오·멀티스레딩·JSI 등)를 AI 코딩 에이전트가 읽는 "스킬(Skill)" 문서 묶음으로 정리한 저장소다. 핵심은 코드가 아니라 마크다운 문서 — 최상위 SKILL.md가 목차 역할을 하고, 세부 문서(reference)는 필요할 때만 로드해 AI의 한정된 기억 공간(컨텍스트)을 아낀다. Claude Code 플러그인으로 한 줄에 설치되며, 스킬 품질을 지키는 Go 린터와 평가(eval) 도구까지 함께 들어 있다. (저장소: software-mansion-labs/skills · 주로 Markdown 스킬 + Go 린터 · ★약 215 · 라이선스 MIT · TrendShift 라이브 멘션 등재)
"코드가 아니라, AI에게 읽힐 '잘 정리된 매뉴얼'을 배포한다."
React Native로 앱을 만들 때 애니메이션·제스처·온디바이스 AI 같은 주제는 함정이 많다. 이 저장소는 그 노하우를 사람용 블로그가 아니라 AI가 직접 읽고 따르는 문서로 정리했다. 플러그인을 깔아 두면, 당신의 AI 도구가 React Native 작업을 할 때 최신·정확한 패턴을 자동으로 참고하게 된다.
SKILL.md 파일이 있고, 그 안에 "언제 이 스킬을 켤지(트리거)"와 "무엇을 따를지(지침)"가 적혀 있다. AI에게 주는 업무 매뉴얼이라고 보면 된다 — 사람을 새로 교육하는 대신, 매뉴얼만 갈아 끼워 AI의 행동을 바꾸는 방식이다.구체적으로 보면 이 저장소의 알맹이는 마크다운(.md) 문서다. 가장 큰 스킬인 react-native-best-practices 하나만 봐도, 최상위 SKILL.md(목차)와 그 아래 애니메이션·제스처·SVG·온디바이스 AI·오디오·멀티스레딩·JSI 등 세부 주제별 폴더로 갈라져 있다. 여기에 Radon IDE 디버깅, TypeGPU, RNRepo, Detour, Fishjam(실시간 영상), Expo Horizon(Meta Quest)까지 총 7개의 상위 스킬이 모여 있다.
SKILL.md(목차)만 읽고, 실제 작업과 관련된 reference 문서만 그때그때 불러온다. 두꺼운 설명서를 통째로 외우는 대신, "필요한 챕터만 펴 보는" 방식. AI의 기억 공간(컨텍스트 윈도)이 한정돼 있기 때문에, 이렇게 아껴 써야 정작 중요한 내용이 밀려나지 않는다.이 문서가 주목하는 건 React Native 기술 자체보다 "AI에게 지식을 주입하는 이 새로운 형식"이다. 스킬은 어떻게 구조화되고, 어떻게 필요할 때만 로드되며, 어떻게 품질을 검사하고, 어떻게 배포되는가 — AI 시대의 지식 패키징을 배우기에 더없이 좋은 실제 사례다.
"누가 만들었나(코어 기여자)"와 "어떻게 만들었나(필요할 때만 펴는 매뉴얼)" 둘 다 화제다.
AI에게 가이드를 주는 시도는 많지만, 이 저장소가 짧은 시간에 트렌딩에 오른 이유는 분명하다.
Software Mansion은 Reanimated·Gesture Handler·React Native SVG 같은, React Native 생태계에서 거의 모두가 쓰는 라이브러리를 직접 만들고 유지하는 회사다(공식 코어 기여자). 즉 이 스킬들은 외부인의 추측이 아니라 라이브러리를 만든 당사자의 1차 지식이다. "신아키텍처(New Architecture)에서 Reanimated 4는 이렇게 쓰라"는 말의 무게가 다르다.
스킬을 그냥 거대한 문서 한 장으로 주면, AI가 그걸 읽느라 정작 당신 코드를 담을 자리가 줄어든다. 이 저장소는 최상위 SKILL.md는 목차만 담고, 세부 내용은 reference 파일로 쪼개 관련된 것만 그때 로드한다. "필요한 페이지만 펴 보는" 이 방식이 AI 스킬 설계의 정석으로 자리잡는 중이다.
그냥 .md 모음이 아니다. 스킬의 형식과 품질을 자동 검사하는 Go 린터, 스킬이 실제로 효과가 있는지 점검하는 평가(eval) 도구, 작업을 묶는 Taskfile과 GitHub Actions까지 갖췄다. "문서도 소프트웨어처럼 테스트하고 CI를 돌린다"는 발상이 신선하다.
마켓플레이스를 추가하고 플러그인을 까는 두 줄, 혹은 npx skills add 한 줄이면 끝난다. 무겁게 설정할 게 없어, 누구나 자기 AI 도구를 즉시 "React Native 전문가"로 만들 수 있다.
| 항목 | 이 저장소(swmansion/skills) | 그냥 긴 프롬프트로 알려주기 | 공식 anthropics/skills |
|---|---|---|---|
| 형태 | 주제별 SKILL.md + reference 묶음(플러그인) | 대화창에 붙여넣는 일회성 글 | 스킬 제작·범용 예제 모음(레퍼런스) |
| 로딩 방식 | 목차만 먼저, 세부는 필요할 때(점진적 공개) | 매번 통째로 붙여야 함 | 스킬별로 동일한 점진적 공개 원칙 |
| 전문 영역 | React Native 신아키텍처 특화 | 그때그때 사람이 적은 만큼 | 도메인 무관 범용·예시 위주 |
| 품질 보증 | Go 린터 + eval + CI 내장 | 없음(사람이 직접) | 스킬 작성 가이드 제공 |
| 설치 | /plugin install 또는 npx skills add | 복붙 | 예제 복제·참고 |
예전엔 AI에게 "Reanimated 4에선 runOnJS 쓰지 마"를 매 대화마다 알려줘야 했다. 이제 플러그인만 깔면 AI가 알아서 그 규칙을 참고한다. 게다가 라이브러리가 업데이트되면 스킬도 갱신되니, "낡은 답변"을 받을 위험도 줄어든다.
첫째, 특정 도구에 묶인다 — 플러그인 설치 형식은 Claude Code(및 호환 CLI) 중심이고, Claude 모델에 최적화돼 있다고 README가 못 박는다. 둘째, 내용이 최신 버전에 강하게 결합돼 있다(예: Reanimated 4, ExecuTorch v0.10.x, TypeGPU 0.11.2) — 라이브러리가 바뀌면 스킬도 따라 갱신돼야 한다. 셋째, 코드를 실행해 주는 게 아니다 — 어디까지나 "이렇게 짜라"는 지침 문서라, 실제 코드는 여전히 AI(혹은 당신)가 작성한다.
"알맹이는 마크다운, 그 둘레를 Go 도구와 플러그인 매니페스트가 감싼다."
이 저장소는 흔한 "웹 앱" 스택이 아니다. 콘텐츠(스킬 문서) · 형식 규약(frontmatter) · 품질 도구(Go) · 배포(플러그인/CLI)라는 네 겹으로 보면 깔끔하다. GitHub은 이 저장소의 주 언어를 Go로 표시하지만(린터·eval 코드 때문), 실제 양으로 보면 대부분은 마크다운 문서다.
| 레이어 | 기술 / 파일 | 역할 |
|---|---|---|
| 스킬 콘텐츠 | Markdown (.md) | 실제 알맹이. 상위 SKILL.md(목차)와 113개+ reference 문서로 노하우를 담음 |
| 스킬 형식 | YAML frontmatter | 각 SKILL.md 맨 위의 name·description. AI가 "언제 이 스킬을 켤지" 판단하는 근거 |
| 품질 린터 | Go (lint/) | skill-lint 바이너리. frontmatter·본문 길이·경로 등 규칙을 자동 검사(아래 상세) |
| 평가(eval) | Go (evals/) | skill-eval. 스킬-크리에이터 작업 결과에 정적 단언(assertion)을 적용해 채점 |
| 작업 러너 | Taskfile (Taskfile.yml) | task lint·task check처럼 명령을 한 단어로 묶음(Makefile의 현대판) |
| CI | GitHub Actions (.github/workflows/lint.yml) | PR마다 린터를 자동 실행해 형식 어긋난 스킬을 걸러냄 |
| 배포 매니페스트 | .claude-plugin/marketplace.json | Claude Code가 읽는 플러그인 카탈로그(이름·설명·키워드·라이선스) |
| 설치 CLI | npx skills (npm) | 플러그인을 안 써도 skills add 한 줄로 스킬을 가져오는 외부 도구 |
---로 감싸 적는 메타데이터 블록. "이 문서가 무엇인지"를 기계가 읽을 수 있게 적어두는 머리표다. 스킬에선 여기에 name(스킬 이름)과 description(언제 켤지 설명)이 들어가고, AI는 이 description을 보고 "지금 이 스킬을 펼칠까?"를 결정한다. 블로그·정적 사이트 글머리에도 흔히 쓰인다.Taskfile.yml에 자주 쓰는 명령을 이름표를 붙여 적어두는 작업 러너(taskfile.dev). 예컨대 길고 복잡한 빌드 명령을 task lint 한 단어로 줄여 준다. 오래된 Makefile을 YAML로 현대화한 도구라고 보면 된다. 이 저장소에선 brew install go-task로 깔고 task --list로 할 수 있는 일을 본다.린터(lint/rules.go)는 단순한 맞춤법 검사가 아니라, 좋은 스킬의 규약을 강제한다. 핵심 규칙을 보면 "스킬을 어떻게 써야 하는가"가 그대로 드러난다.
| 규칙 | 무엇을 / 왜 |
|---|---|
| frontmatter 필수 | SKILL.md는 반드시 ---로 시작해야 함. name·description 없으면 실패 |
| name 규약 | 64자 이하, 소문자·숫자·하이픈만. anthropic·claude 같은 예약어 금지 |
| description 규약 | 1024자 이하, 3인칭으로("you can…" 같은 2인칭 시작 금지), "Use when…/Trigger on:" 같은 트리거 문구 포함 권장 |
| 본문 길이 | 본문 500줄 이하 권장 — 길면 reference 파일로 쪼개라(점진적 공개 강제) |
| 경로·시간 표현 | 윈도식 역슬래시 경로 금지(/ 사용), "최근/곧" 같은 시간 의존 표현 경고 |
| 참조 깊이 | reference가 또 다른 reference를 깊게 물고 들어가지 않도록(얕게 유지) 검사 |
여기서 보이듯, 린터 자체가 "좋은 에이전트 스킬이란 무엇인가"의 체크리스트다. 트리거 문구를 넣어라, 3인칭으로 써라, 너무 길면 쪼개라 — 이 규칙들을 읽는 것만으로도 스킬 작성법을 배울 수 있다.
"내가 'React Native 애니메이션 어떻게 해?'라고 물으면, 어떤 SKILL.md와 reference가 어떤 순서로 펼쳐지나."
이 저장소의 진짜 설계는 폴더 구조가 아니라 "문서가 AI에게 도달하는 순서"에 있다. 핵심은 한 번에 다 주지 않고 목차 → 관련 챕터만 순으로 펼치는 점진적 공개다. 전체 그림을 먼저 보자.
스킬은 중첩된 목차 구조다. 최상위 SKILL.md는 "어떤 주제가 있는지"만 표로 나열하고, 각 주제 폴더의 SKILL.md가 다시 "그 주제 안 세부 문서"를 표로 나열한다. 실제 최상위 목차의 일부를 보자(읽기 쉽게 정리).
# skills/react-native-best-practices/SKILL.md (발췌)
---
name: react-native-best-practices
description: "...MUST USE before writing ANY code in a React Native
or Expo project... Trigger on: 'Reanimated', 'Gesture Handler',
'svg', 'animation', 'gesture', 'audio', 'rich text', ..."
license: MIT
---
## Sub-skills # ← 이 표가 '목차'다
| Sub-skill | When to use |
|---------------------------------|--------------------------------|
| references/animations/SKILL.md | CSS transitions, withSpring... |
| references/gestures/SKILL.md | tap, pan, pinch, swipe, drag |
| references/svg/SKILL.md | vector graphics, icons, charts |
| references/on-device-ai/SKILL.md| LLMs, OCR, embeddings... |
| references/jsi/SKILL.md | C++ JS Interface, HostObject...|읽는 법은 단순하다. 표의 왼쪽은 "어디로 가면 되는지(경로)", 오른쪽은 "언제 거기로 가야 하는지(트리거)"다. AI는 작업 키워드를 오른쪽과 맞춰 보고, 맞는 행의 왼쪽 경로 문서만 추가로 읽는다. 이 한 장(목차)만 항상 메모리에 있고, 나머지는 필요할 때만 들어온다.
description 문장. 여기에 "Reanimated", "gesture", "svg" 같은 실제로 등장할 법한 단어를 잔뜩 넣어 둔다. AI는 사용자 요청·프로젝트 파일에서 이 단어들을 발견하면 해당 스킬을 펼친다. 즉 description은 설명문이 아니라 "이 매뉴얼을 꺼낼 검색 키워드 목록"에 가깝다. 린터가 "트리거 문구를 넣어라"라고 검사하는 이유다.각 주제 SKILL.md에는 종종 "Load at most one reference file per question"(질문당 reference는 많아야 한 장만 읽어라)이라는 규칙이 적혀 있다. 또 API 시그니처처럼 잘 바뀌는 세부는 문서에 다 적지 말고 필요할 때 공식 문서를 webfetch하라고 안내한다. 둘 다 같은 목적이다 — AI의 기억 공간을 한 푼이라도 아끼는 것.
스킬 묶음은 잘 정리된 도서관이다. 최상위 SKILL.md는 입구의 안내판("애니메이션은 3층, 제스처는 4층"), 주제별 SKILL.md는 그 층의 서가 표지판, reference 파일은 실제 책이다. 똑똑한 사서(AI)는 도서관 전체를 머리에 넣지 않는다 — 안내판을 보고 필요한 책 한 권만 꺼내 온다. 그래야 손(컨텍스트)이 비어 있어 당신이 맡긴 일(코드)을 들 수 있다.
위 부품들이 어떻게 맞물리는지, 가장 단순한 흐름 하나로 따라가 보자.
// "RN 리스트 아이템에 페이드인 넣어줘" 요청의 내부 순서 (개념)
① 작업 키워드 'animation' 감지 → react-native-best-practices 스킬 켜짐
② 최상위 SKILL.md 의 Sub-skills 표에서 'animations' 행 매칭
③ references/animations/SKILL.md 로드 — Critical Rule 확인:
"NEVER use runOnJS (Reanimated 4 에서 제거됨). scheduleOnRN 써라"
④ animations 의 reference 표에서 진입/퇴장 애니메이션 → layout-animations.md
⑤ layout-animations.md 한 장만 로드 (FadeIn/itemLayoutAnimation 상세)
⑥ (선택) 정확한 옵션이 필요하면 공식 docs 를 webfetch
⑦ AI 가 그 규칙대로 코드 작성 — runOnJS 안 쓰고 scheduleOnRN 사용여기서 배울 핵심은 "열린 문서"와 "안 열린 문서"의 차이다. 이 한 번의 작업에서 실제로 메모리에 들어온 건 목차 두 장 + 본문 한 장뿐이고, 제스처·SVG·오디오·JSI 같은 다른 스킬과 animations의 나머지 reference 8장은 건드리지도 않았다. 스킬이 아무리 방대해도 한 작업의 비용이 작게 유지되는 비결이다.
"폴더는 단순하다 — 스킬(콘텐츠) + 도구(Go) + 매니페스트, 딱 세 덩어리."
루트에는 스킬 콘텐츠 폴더 skills/, Go 도구 둘(lint/·evals/), 플러그인 매니페스트 .claude-plugin/, 그리고 작업 러너 Taskfile.yml이 있다. 대부분의 부피는 skills/ 안 마크다운에 있다.
| 경로 | 역할 |
|---|---|
| skills/ | 각 스킬의 입구이자 목차. frontmatter(name·description) + 세부 문서 표 |
| .../references/ | 점진적 공개의 본문들. 주제별로 잘게 쪼갠 .md (총 113개+) |
| .claude-plugin/ | 플러그인 배포 정보. /plugin marketplace add가 읽음 |
| lint/ | 형식 경찰. skill-lint 빌드·실행, frontmatter/길이/경로 규칙 |
| evals/ | 효과 측정. 스킬-크리에이터 결과에 정적 단언을 적용해 채점 |
| Taskfile.yml | 위 작업들을 task lint·task check 한 단어로 묶는 진입점 |
| .github/workflows/lint.yml | PR마다 린터 자동 실행(CI) |
처음 읽는다면 길잡이는 이렇다. 스킬이 어떻게 생겼는지 궁금하면 skills/react-native-best-practices/SKILL.md(목차) → references/animations/SKILL.md(하위 목차) → 그 안의 .md 한 장 순으로. "좋은 스킬의 규칙"이 궁금하면 lint/rules.go를, 설치·기여 방법은 루트 README.md를 보면 된다.
animations.md·layout-animations.md·gpu-animations.md처럼 잘게 나눈다. 작게 쪼개야 "정확히 필요한 한 조각만" 로드할 수 있다 — 이게 폴더가 깊어 보이는 진짜 이유다(낭비가 아니라 절약을 위한 설계)."이 저장소 한 채에 '에이전트 스킬 작성·컨텍스트 관리·품질 보증·플러그인 배포'가 다 있다."
React Native에 관심이 없어도 배울 게 많다. 분야별로 무엇을 배울지 + 작게 실습할 아이디어를 정리했다.
배울 것: AI가 따르는 문서를 어떻게 구조화하나. frontmatter의 name·description, 그리고 "언제 켤지"를 정하는 트리거 단어 설계. 아래가 가장 작은 스킬의 뼈대다.
# 가장 단순한 SKILL.md 골격
---
name: my-skill
description: "Use when ... . Trigger on: 'keyword1', 'keyword2'."
---
# My Skill
한두 문단의 핵심 지침.
## References
| File | When to read |
|---------------|------------------------|
| details.md | 세부 사항이 필요할 때 |실습: 위 골격으로 나만의 작은 SKILL.md를 적고, description에 트리거 단어를 3~5개 넣어 보기. 본문은 짧게, 세부는 details.md로 분리.
배울 것: "목차는 항상, 본문은 필요할 때만" 패턴. 최상위 SKILL.md는 표(목차)만, 세부는 reference로 빼고 "질문당 한 장만 읽어라" 같은 규칙으로 로딩을 통제하는 법. AI의 기억 공간이 곧 비용이라는 감각.
실습: react-native-best-practices/SKILL.md → references/animations/SKILL.md → 그 안 .md 한 장으로 이어지는 3단 목차를 직접 따라 읽으며 "무엇이 안 열렸나"를 적어 보기.
배울 것: "문서도 테스트한다"는 발상. Go로 짠 린터가 frontmatter·본문 길이·경로·트리거 문구를 자동 검사하고(lint/rules.go), eval이 정적 단언으로 스킬 효과를 채점한다. CI(lint.yml)가 PR마다 이를 돌린다.
실습: task lint:test로 린터 유닛 테스트를 돌려 보고, rules.go의 규칙 목록을 "좋은 스킬 체크리스트"로 베껴 보기. 일부러 규칙을 어긴 SKILL.md를 만들어 경고가 뜨는지 확인.
배울 것: 스킬 묶음을 한 줄로 설치되는 플러그인으로 포장하는 법. .claude-plugin/marketplace.json에 이름·설명·키워드·라이선스를 적고, 사용자가 /plugin marketplace add → /plugin install로 받게 만드는 구조.
실습: marketplace.json을 읽고 각 필드(name·source·keywords·category)가 무슨 역할인지 정리. npx skills add ... 설치 경로와 무엇이 다른지 비교.
배울 것: 스킬 내용 자체도 훌륭한 교재다. Reanimated 4(애니메이션)·Gesture Handler(제스처)·ExecuTorch(온디바이스 AI)·JSI(C++↔JS 다리)·Worklets(멀티스레딩) 같은 신아키텍처 핵심 주제의 "실수하기 쉬운 지점"이 압축돼 있다.
실습: jsi/SKILL.md나 on-device-ai/SKILL.md의 목차 표만 훑어도 "이 분야에 뭐가 있는지" 지도가 그려진다. 관심 가는 reference 한 장(예: vision.md)을 골라 읽어 보기.
"쓰는 건 거의 무료(설치 한 줄), 개발(린터·eval 빌드)에만 Go가 필요하다."
순수 소프트웨어이고 대부분 텍스트라, "쓰기"와 "개발하기"의 요구가 크게 다르다.
| 구성 | 요구사항 |
|---|---|
| AI 에이전트 | Claude Code(또는 플러그인/스킬 형식을 지원하는 호환 CLI). Claude 모델에 최적화돼 있다고 README 명시 |
| npx 설치 시 | Node.js(npx 포함). npx skills add ...로 플러그인 없이도 설치 가능 |
| 네트워크 | GitHub에서 스킬을 받아오고, 일부 스킬은 작업 중 공식 문서를 webfetch |
| 구성 | 요구사항 |
|---|---|
| Go | Go 1.25+ — 린터(skill-lint)와 eval(skill-eval) 빌드용 |
| Task | go-task(brew install go-task) — task lint·task check 실행기 |
| (선택) RN 환경 | 스킬 내용을 실제로 검증하려면 React Native/Expo 프로젝트가 따로 필요(스킬 자체엔 불필요) |
# 1) 플러그인으로 설치 (권장) — Claude Code 안에서
/plugin marketplace add software-mansion-labs/skills
/plugin install skills@swmansion
/reload-plugins
# 최신화: /plugin marketplace update swmansion
# 2) 또는 npx 한 줄로
npx skills add software-mansion-labs/skills
# 3) 개발: 린터/체크 돌리기 (저장소를 clone 한 뒤)
brew install go-task # Task 설치
task --list # 할 수 있는 작업 보기
task lint # 모든 스킬에 린터 실행
task check # lint + 유닛 테스트복사해서 그대로 써도 된다. 핵심은 "쓰는 사람은 설치 한 줄, 기여하는 사람만 Go·Task"라는 점이다. 콘텐츠가 마크다운이라 무거운 런타임이 없고, 무게는 오로지 품질 도구(Go) 쪽에만 있다.
"읽기만 하면 안 남는다 — 난이도별로 손을 움직여 보자."
Claude Code에서 /plugin marketplace add software-mansion-labs/skills → /plugin install skills@swmansion으로 설치한다. 그 뒤 React Native 관련 질문을 던져, 어떤 스킬이 자동으로 켜지는지 관찰. "스킬이 트리거된다"는 감각을 직접 체험한다.
react-native-best-practices/SKILL.md를 열어 frontmatter(name·description)와 Sub-skills 표를 구분해 읽는다. description 안에서 "트리거 단어"가 몇 개나 되는지 세어 보고, 표의 "왼쪽=경로 / 오른쪽=언제"를 메모. 스킬의 뼈대가 한눈에 들어온다.
아무 주제(예: "내 회사 깃 커밋 규칙")로 SKILL.md 한 장을 짠다. frontmatter + 한두 문단 + references 표 골격을 지키고, description에 트리거 단어를 넣는다. 본문이 길어지면 details.md로 분리해 점진적 공개를 연습.
저장소를 clone한 뒤 task lint·task lint:test를 실행한다. 그다음 내 SKILL.md의 name에 대문자를 넣거나 본문을 500줄 넘게 부풀려 어떤 경고가 뜨는지 확인. "좋은 스킬의 규칙"을 몸으로 익힌다.
긴 스킬 하나를 골라, 한 챕터를 별도 reference .md로 떼어내고 상위 SKILL.md 표에 등록하는 "분할 리팩터링"을 연습한다. README의 Contributing 절(새 sub-skill 추가 4단계)을 따라, 오타 수정이나 새 트리거어 추가 같은 첫 PR을 시도(린터 CI 통과 경험).
"마크다운 기초에서, 나만의 스킬 플러그인을 배포하기까지 — 6주 코스 예시."
아래는 "AI 에이전트 스킬을 이해하고 직접 만들어 배포할 수 있는 수준"까지의 한 가지 길이다. 본인 속도에 맞춰 늘리거나 줄여도 된다.
| 주차 | 주제 | 학습 자료 / 무엇을 · 왜 |
|---|---|---|
| 1주 | 스킬·점진적 공개 개념 | 이 저장소 README + 최상위 SKILL.md 읽기. "목차→본문" 로딩 모델을 이해 — 모든 것의 출발점 |
| 2주 | frontmatter & 트리거 설계 | animations/SKILL.md 등 description을 여러 개 비교. "어떤 단어를 넣어야 잘 켜지나"를 패턴화. Anthropic의 Agent Skills 문서 병행 |
| 3주 | 마크다운 + 분할 설계 | 긴 스킬이 어떻게 reference로 쪼개졌는지 분석. 500줄 규칙·"한 장만 읽어라" 규칙의 이유를 컨텍스트 비용과 연결 |
| 4주 | 품질 도구(Go) 읽기 | lint/rules.go 정독 → "좋은 스킬 체크리스트" 작성. task lint·lint:test 직접 실행. eval(evals/) 개념 파악 |
| 5주 | 플러그인 배포 구조 | .claude-plugin/marketplace.json 분석 → 나만의 마켓플레이스/플러그인 매니페스트 작성. /plugin 명령 흐름 이해 |
| 6주 | 나만의 스킬 패키지 | 1~5주를 합쳐 작은 스킬 1~2개를 만들고 린터 통과 → README 기여 가이드대로 PR 또는 자체 마켓플레이스로 배포 |
이 저장소를 배우는 건 요리책 출판사 견학 같다. 처음부터 React Native 요리법(내용)을 다 외울 필요는 없다. "레시피 카드 양식(SKILL.md·frontmatter) → 목차 구성(점진적 공개) → 교정·검수(린터·eval) → 서점 입고(플러그인 배포)" 식으로 '책 만드는 과정'을 단계별로 익히는 게, 113장의 reference를 한입에 삼키려다 체하는 것보다 낫다.
"이 문서와 스킬 저장소에서 거듭 나오는 용어들 — 한 곳에 모아 풀었다."
SKILL.md가 핵심이며, AI에게 주는 업무 매뉴얼에 해당한다.SKILL.md)만 먼저 로드하고 본문(reference)은 관련될 때만 불러와, AI의 컨텍스트(기억 공간)를 아낀다.---로 감싸 적는 메타데이터. 스킬에선 name(이름)과 description(언제 켤지)이 들어가며, AI는 이 description으로 스킬 발동 여부를 판단한다.marketplace.json). /plugin marketplace add → /plugin install로 받는다.HostObject·HostFunction 등을 통해 zero-copy로 데이터를 넘기며, TurboModules·Nitro Modules의 토대가 된다.runOnJS 대신 scheduleOnRN을 쓴다.useLLM·useOCR 같은 훅으로 채팅·이미지 분류·음성 인식 등을 오프라인·프라이버시 보존 방식으로 제공한다.d.*)가 GPU 타입·버퍼 레이아웃·TS 타입을 동시에 정의한다.공식 저장소·제작사·관련 문서.
GitHub 저장소 · github.com/software-mansion-labs/skills — 본체. skills/react-native-best-practices/SKILL.md(목차)와 lint/rules.go(스킬 규칙)부터 보면 좋다.
Software Mansion · swmansion.com — 제작사. Reanimated·Gesture Handler·React Native SVG 등을 만든 코어 기여자 팀.
공식 anthropics/skills (비교) · github.com/anthropics/skills — Anthropic의 스킬 예제·가이드 모음. 같은 "점진적 공개" 원칙을 도메인 무관 범용으로 보여준다.
Claude Code 플러그인 문서 · code.claude.com/docs/en/plugins — 플러그인·마켓플레이스 제작 방법.
Agent Skills 문서 · code.claude.com/docs/en/skills — SKILL.md 형식과 트리거 description 작성법.
skills CLI · npmjs.com/package/skills — 플러그인 없이 npx skills add로 설치하는 도구.