TL;DR
- 1인 시그니처 스킬팩이 표준 배포 단위가 되고 있다. 2026-04-15 forrestchang/andrej-karpathy-skills, 2026-04-29 addyosmani/agent-skills, 2026-04-30 mattpocock/skills가 모두 GitHub 트렌딩 1위권에 진입 — 2주 안에 유명인이 자기 작업 방식을 통째로 SKILL.md로 패키징하는 모먼트가 수렴했다.
- 세 팩의 성격은 정확히 다르다:
- Karpathy: 스킬 1개·67줄, 행동 규약. 모델이 코드 쓰러 가기 전 4가지 자세만 박는다.
- Matt Pocock: 28개·6 카테고리, 워크플로 슬래시 커맨드 모음. PRD → 이슈 → 다이어그노즈 → 리팩토링까지 입력 단계마다 슬래시 1개씩.
- Addy Osmani: 22개·평탄, X-driven development·X engineering 명사구로 통일된 방법론 카탈로그.
- 같이 깔면 이름 충돌(
tddvstest-driven-development,diagnosevsdebugging-and-error-recovery)과 디시플린 중복(spec/TDD/디버깅이 두세 군데에 동시 존재)이 생긴다. §4에 어떻게 갈래를 잡을지 정리. - 권장 조합: 누구 한 명만 깔 거면 Addy. 슬래시 워크플로가 필요하면 Matt를 골라서. Karpathy는 어떤 조합 위에도 얹어도 무리 없다 — 가장 가볍다.
개요 — 왜 셋을 같이 보는가
Agent Skill 시리즈 개요에서 "스킬은 프롬프트·컨텍스트 다음의 설계 단위"라고 깔았다. Superpowers 글에서는 프레임워크형 메타스킬 묶음을 봤다. 이번 글은 개인이 자기 작업 방식을 통째로 SKILL.md로 패키징한 시그니처 팩을 다룬다.
세 팩이 같이 묶이는 이유는 발표자 본인이 도메인 권위자라는 점이다. Karpathy는 OpenAI 창립 멤버·Tesla AI 디렉터·전 마이크로소프트 AI Residency 멘토, Matt Pocock은 TypeScript 분야 가장 영향력 큰 강사 중 하나, Addy Osmani는 Google Chrome DevRel 엔지니어링 리더. 셋 다 자기 워크플로를 SKILL.md 한 묶음으로 옮긴다는 결정을 비슷한 시점에 동시에 했다.
| 팩 | 스킬 수 | 구조 | 성격 |
|---|---|---|---|
forrestchang/andrej-karpathy-skills |
1 | 단일 SKILL.md | 행동 규약 |
mattpocock/skills |
28 | 6 카테고리 | 워크플로 슬래시 커맨드 |
addyosmani/agent-skills |
22 | 평탄 | 방법론 카탈로그 |
본문은 Karpathy → Matt → Addy 순. 각 섹션의 형태는 팩 성격에 맞춘다 — Karpathy는 스킬이 하나라 시그니처·표가 어색하므로 핵심 지침 인용으로 대체, Matt·Addy는 시그니처 5-6개 + 전체 표 토글.
1. Karpathy — 지침 한 장으로 모델 행동을 깎는다
forrestchang/andrej-karpathy-skills는 Andrej Karpathy가 X에 올린 LLM 코딩 함정 메모를 단일 SKILL.md로 재포장한 결과물이다. 정확히 스킬 1개·67줄. Karpathy 본인 레포가 아니라 forrestchang(커뮤니티)이 옮긴 거지만, 4월 15일 GitHub 트렌딩 2위로 진입한 후 Karpathy 시그니처로 사실상 정착했다.
1.1. 핵심 4개 지침 (인용)
SKILL.md의 본문은 단 네 개 섹션으로 끝난다:
- Think Before Coding — Don't assume. Don't hide confusion. Surface tradeoffs. 가정을 명시하고, 불확실하면 멈춰서 묻고, 여러 해석이 있으면 고르지 말고 제시.
- Simplicity First — Minimum code that solves the problem. Nothing speculative. 요청 외 기능 금지, 단일 사용 코드에는 추상화 금지, 200줄로 짠 걸 50줄로 줄일 수 있으면 다시 쓴다.
- Surgical Changes — Touch only what you must. Clean up only your own mess. 주변 코드·포맷·코멘트 멋대로 손대지 않고, 자기가 만든 고아 import만 정리, 기존 dead code는 언급만 하고 지우지 않음.
- Goal-Driven Execution — Define success criteria. Loop until verified. "버그 고쳐"가 아니라 "버그를 재현하는 테스트 작성 후 통과시켜"로 변환. 강한 성공 기준이 있어야 모델이 알아서 루프를 돈다.
1.2. 언제 쓰면 좋은가
- 모델이 코드를 곧장 쓰러 가는 걸 막고 싶을 때. 4개 지침 모두 "쓰기 전에 멈춘다"가 공통 줄기다.
- 어떤 프로젝트에도 같이 까는 베이스 디시플린으로. 67줄·시스템 프롬프트 후미에 박아 두면 다른 어떤 스킬·CLAUDE.md와도 충돌하지 않는다 — 동작 규약이지 워크플로가 아니라서 슬래시 명령·우선순위·자가 호출이 없다.
- 반대로 워크플로가 필요하면 부족하다. Karpathy 팩은 "코드 쓰기 전 자세"만 박을 뿐, "PRD를 어떻게 만들고, 이슈를 어떻게 쪼개고, 디버깅을 어떻게 하는지"는 다루지 않는다 — 그건 Matt·Addy 영역.
2. Matt Pocock — 워크플로 슬래시 커맨드 28개
mattpocock/skills. 4월 30일 GitHub 트렌딩에 +7.2k 스타/일로 진입. 28개 스킬을 6 카테고리(deprecated·engineering·in-progress·misc·personal·productivity)로 묶었다 — 현재 운영용·실험용·도메인 특화·생활용을 디렉토리 단위로 분리한 게 특징이다.
2.1. 시그니처 6개
grill-with-docs (engineering)
Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise.
Matt의 시그니처 중 시그니처. 사용자 플랜을 그냥 듣지 않고 프로젝트의 CONTEXT.md·ADR과 대조하며 추궁한다. 결정이 굳어질 때마다 그 자리에서 ADR을 업데이트한다. 언제: 새 기능·아키텍처 결정 전에 도메인 모델과 정합성을 강제로 맞추고 싶을 때.
grill-me (productivity)
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree.
grill-with-docs의 도메인 없는 버전. 사용자가 자기 디자인을 짧게 던지면 모델이 트리의 모든 분기를 거꾸로 질문해서 결정 트리 전부를 굳히도록 강제한다. 언제: 머릿속에서만 흐릿하게 굴리고 있는 디자인을 stress-test하고 싶을 때.
caveman (productivity)
Ultra-compressed communication mode. Cuts token usage ~75% by dropping filler, articles, and pleasantries while keeping full technical accuracy.
본인 트레이드마크. 기술 정확도는 유지하되 관사·완곡어·헤지·접속사를 통째로 떨궈 토큰을 4분의 1로 줄인다. Drop: articles (a/an/the), filler (just/really/basically), pleasantries (sure/certainly/of course), hedging. 언제: 긴 세션이 컨텍스트를 잡아먹기 시작할 때, 또는 출력 토큰 비용을 강제로 줄여야 할 때.
zoom-out (engineering)
Tell the agent to zoom out and give broader context or a higher-level perspective.
Matt는 "Claude가 디테일에 매몰됐다 판단 시 zoom-out 자동 발동"이 본인 글로벌 CLAUDE.md에 박혀 있을 정도로 자주 쓴다. 언제: 모델이 좁은 파일·함수에 갇혀서 왜 이 작업을 하는지가 빠지기 시작했을 때.
to-prd / to-issues (engineering, 한 쌍)
Turn the current conversation context into a PRD and publish it to the project issue tracker. / Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices.
브레인스토밍 → PRD → 이슈 쪼개기를 슬래시 두 번으로 끝낸다. tracer-bullet vertical slice(첫 이슈가 전체 시스템을 얇게 관통하는 형태)를 디폴트로 강제. 언제: 슬랙 대화·미팅 노트가 PRD로 굳어야 하는 시점, 그리고 PRD가 AFK 에이전트가 알아서 집어가는 이슈로 분해돼야 하는 시점.
diagnose (engineering)
Disciplined diagnosis loop for hard bugs and performance regressions. Reproduce → minimise → hypothesise → instrument → fix → regression-test.
6단계 디버깅 루프를 강제하는 슬래시. Superpowers의 systematic-debugging과 매우 가깝지만 재현·최소화를 더 강조한다 — 버그를 코드의 최소 단위로 압축한 다음에 가설을 세우라는 규약. 언제: "어딘가 안 되는데" 류 모호한 버그·성능 회귀.
2.2. 언제 쓰면 좋은가 (전체)
- PRD·이슈 트래커 위에서 일하는 팀.
to-prd·to-issues·triage트리오가 이 팩의 진짜 메인. GitHub Issue가 첫 시민인 워크플로에 가장 잘 맞는다. - 글쓰기까지 동일 도구로 처리하고 싶은 1인.
in-progress/writing-*·personal/edit-article등 글 쓰는 사람의 슬래시가 같이 들어 있다. - 반대로 풀스택 디시플린 패키지로 기대하면 약하다. TDD·디버깅·검증 등의 강제 게이트는 Superpowers·Addy 쪽이 더 두껍다. Matt는 입력 단계의 의식(ritual)에 강점이 있고, 코드 작성 디시플린은 가볍게만 다룬다.
2.3. 28개 전체 표
mattpocock/skills 28개 전체 표 펼치기
| 카테고리 | 스킬 | 한 줄 |
|---|---|---|
| engineering | diagnose |
디버깅·성능 회귀용 6단계 진단 루프 (재현 → 최소화 → 가설 → 계측 → 수정 → 회귀 테스트) |
| engineering | grill-with-docs |
플랜을 CONTEXT.md·ADR과 대조하며 추궁, 결정 굳을 때마다 인라인 문서 업데이트 |
| engineering | improve-codebase-architecture |
CONTEXT.md·ADR 기반으로 리팩토링·deepening 기회 탐색 |
| engineering | prototype |
디자인 확정 전 던지는 프로토타입(터미널 실행본 vs 단순 코드 트리) |
| engineering | setup-matt-pocock-skills |
AGENTS.md/CLAUDE.md에 ## Agent skills 블록과 docs/agents/ 스캐폴딩 |
| engineering | tdd |
red-green-refactor 루프 강제 |
| engineering | to-issues |
플랜·PRD를 tracer-bullet vertical slice 이슈로 분해 |
| engineering | to-prd |
현재 대화 컨텍스트를 PRD로 만들어 이슈 트래커에 게시 |
| engineering | triage |
들어온 이슈를 triage role 상태머신으로 처리 |
| engineering | zoom-out |
디테일 매몰된 모델을 넓은 컨텍스트로 끌어올림 |
| productivity | caveman |
토큰 약 75% 압축(관사·필러·헤지 제거, 기술 정확도 유지) |
| productivity | grill-me |
사용자 플랜을 결정 트리 전 분기까지 추궁 |
| productivity | handoff |
현재 대화를 다른 에이전트가 픽업 가능한 핸드오프 문서로 압축 |
| productivity | write-a-skill |
progressive disclosure 구조로 새 스킬 작성 |
| in-progress | review |
고정 기준점(커밋·브랜치) 이후 변경을 Standards/Behaviour 2축으로 리뷰 |
| in-progress | writing-beats |
글을 beats 단위로 분해해 choose-your-own-adventure로 재구성 |
| in-progress | writing-fragments |
사용자에서 글 조각(claim·vignette·문장) 채굴 |
| in-progress | writing-shape |
원자료 마크다운을 대화로 다듬어 article로 |
| misc | git-guardrails-claude-code |
Claude Code 훅으로 위험한 git 명령(push·reset --hard·branch -D) 차단 |
| misc | migrate-to-shoehorn |
TS 테스트의 as 단언을 @total-typescript/shoehorn으로 마이그레이션 |
| misc | scaffold-exercises |
section·problem·solution·explainer 구조의 연습문제 디렉토리 스캐폴딩 |
| misc | setup-pre-commit |
Husky pre-commit + lint-staged(Prettier·typecheck·test) 셋업 |
| personal | edit-article |
글의 구조·명료성·간결성 개선 |
| personal | obsidian-vault |
옵시디언 vault에서 노트 검색·생성·관리 |
| deprecated | design-an-interface |
모듈 인터페이스 디자인을 병렬 서브에이전트로 다수 생성 |
| deprecated | qa |
사용자 대화형 QA → GitHub 이슈 자동 생성 |
| deprecated | request-refactor-plan |
사용자 인터뷰로 작은 커밋 리팩토링 플랜 작성 후 이슈 등록 |
| deprecated | ubiquitous-language |
현재 대화에서 DDD 스타일 ubiquitous language 글로서리 추출 |
3. Addy Osmani — X-driven development 22개 카탈로그
addyosmani/agent-skills. 4월 29일 등장 다음 날 +3k 스타/일, 2일 연속 트렌딩 1위권. 카테고리 디렉토리가 없고 22개 스킬이 평탄하게 펼쳐져 있으며, 이름이 거의 다 X-driven development 또는 X engineering 같은 명사구로 통일됐다 — 방법론 카탈로그에 가깝다.
3.1. 시그니처 6개
using-agent-skills (메타)
Discovers and invokes agent skills. Use when starting a session or when you need to discover which skill applies to the current task. This is the meta-skill that governs how all other skills are discovered and invoked.
Addy 팩의 부트스트랩. Superpowers의 using-superpowers와 같은 역할 — 다른 21개 스킬의 발견·호출 규약을 가장 먼저 깐다. 언제: 팩을 깔자마자 SessionStart에 자동 주입되도록 묶어두면 나머지 스킬의 자가 호출률이 올라간다.
spec-driven-development
Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet.
Spec 우선 원칙과 정확히 같은 결 — "spec이 없으면 코드 금지"를 디시플린으로 만든다. 언제: 새 프로젝트·새 기능, 또는 요구사항이 모호한 아이디어로만 존재할 때.
doubt-driven-development
Subjects every non-trivial decision to a fresh-context adversarial review before it stands. Use when correctness matters more than speed, when stakes are high (production, security-sensitive logic, irreversible operations).
Addy의 시그니처. 비-트리비얼 결정마다 프레시 컨텍스트 어드버서리얼 리뷰(별도 컨텍스트의 모델에게 반박해 보라고 시키는 것)를 강제. 언제: 정확성이 속도보다 중요한 자리 — 프로덕션 변경·보안 로직·되돌리기 어려운 작업. 한 마디로 Adversary as a service.
source-driven-development
Grounds every implementation decision in official documentation. Use when you want authoritative, source-cited code free from outdated patterns.
모든 구현 결정에 공식 문서 인용을 요구한다. LLM이 학습 시점의 구식 패턴을 그대로 재생산하는 걸 막는 게 목적. 언제: 새 프레임워크·새 버전의 라이브러리를 다루는데 모델 학습 데이터가 낡았을 가능성이 있을 때.
context-engineering
Optimizes agent context setup. Use when starting a new session, when agent output quality degrades, when switching between tasks, or when you need to configure rules files and context for a project.
세션 시작·태스크 전환 시점의 규칙 파일과 컨텍스트 셋업을 표준화한다. CLAUDE.md·AGENTS.md·룰 파일 관리 가이드라인이 본체. 언제: 출력 품질이 떨어지기 시작했을 때 (보통 컨텍스트 오염이 원인).
incremental-implementation
Delivers changes incrementally. Use when implementing any feature or change that touches more than one file. Use when you're about to write a large amount of code at once, or when a task feels too big to land in one step.
여러 파일을 한 번에 갈아엎으려는 모델을 증분 커밋 단위로 자르도록 강제한다. 언제: 모델이 한 응답에 200줄짜리 변경을 시도하려 할 때 — 이 스킬이 덩어리를 잘게 자른다.
3.2. 언제 쓰면 좋은가 (전체)
- 풀스택 디시플린 한 묶음으로. 22개 중 절반 가까이가 X-driven development(spec/test/doubt/source) — Superpowers의 게이트와 가장 비슷한 풀패키지.
- 프론트엔드를 메인으로 다루는 사람. Addy가 Chrome DevRel이라
frontend-ui-engineering·browser-testing-with-devtools같은 프론트 특화 스킬이 있다 — Matt 팩에는 없는 자리. - 반대로 슬래시 한 방으로 PRD·이슈 만들기는 약하다. Addy는 디시플린 명사구에 가깝고 Matt는 워크플로 동사구에 가깝다 — 동시에 깔면 보완 관계 (§4).
3.3. 22개 전체 표
addyosmani/agent-skills 22개 전체 표 펼치기
| 분류 | 스킬 | 한 줄 |
|---|---|---|
| 메타 | using-agent-skills |
다른 스킬의 발견·호출 규약을 깐 부트스트랩 |
| 방법론(driven) | spec-driven-development |
코딩 전 spec 작성 |
| 방법론(driven) | test-driven-development |
테스트로 동작 증명 |
| 방법론(driven) | doubt-driven-development |
결정마다 프레시 컨텍스트 어드버서리얼 리뷰 |
| 방법론(driven) | source-driven-development |
모든 결정에 공식 문서 인용 |
| 작업 흐름 | planning-and-task-breakdown |
작업을 순서 있는 태스크로 분해 |
| 작업 흐름 | incremental-implementation |
다중 파일 변경을 증분 커밋 단위로 분할 |
| 작업 흐름 | idea-refine |
발산 → 수렴 사고로 아이디어 다듬기 |
| 작업 흐름 | context-engineering |
세션 시작·전환 시점의 컨텍스트·룰 파일 셋업 |
| 코드 품질 | code-review-and-quality |
머지 전 다축 코드 리뷰 |
| 코드 품질 | code-simplification |
코드를 더 명료하게 단순화 |
| 코드 품질 | debugging-and-error-recovery |
근본 원인 디버깅 가이드 |
| 코드 품질 | security-and-hardening |
취약점에 대한 코드 강화 |
| 코드 품질 | performance-optimization |
애플리케이션 성능 최적화 |
| 도메인 | frontend-ui-engineering |
프로덕션급 UI 구현 |
| 도메인 | browser-testing-with-devtools |
실제 브라우저에서 테스트 |
| 도메인 | api-and-interface-design |
안정적 API·인터페이스 디자인 |
| 운영 | git-workflow-and-versioning |
git 워크플로 표준화 |
| 운영 | ci-cd-and-automation |
CI/CD 파이프라인 자동화 |
| 운영 | documentation-and-adrs |
결정 기록과 문서화 |
| 운영 | deprecation-and-migration |
디프리케이션·마이그레이션 관리 |
| 운영 | shipping-and-launch |
프로덕션 런치 준비 |
분류 칼럼은 본 글에서 정리용으로 부여 — 원본 레포는 평탄 구조다.
4. 충돌 가능성 — 셋을 동시에 깔면 어디서 깨지나
아래는 셋을 동시에 깔아 직접 겪은 관찰이 아니라, 각자의 SessionStart 훅·README·정의 파일·공식 이슈를 읽고 충돌이 구조적으로 필연인 지점만 짚은 것이다.
4.1. 이름 충돌·디시플린 중복
세 팩에 같은 일을 하는 스킬이 둘씩 들어 있다:
| 일 | Karpathy | Matt | Addy |
|---|---|---|---|
| TDD | (지침 §4 Goal-Driven) | engineering/tdd |
test-driven-development |
| 디버깅 | (없음) | engineering/diagnose |
debugging-and-error-recovery |
| 스킬 작성 | (없음) | productivity/write-a-skill |
(Superpowers의 writing-skills로 대체 가능) |
| 코드 리뷰 | (없음) | in-progress/review |
code-review-and-quality |
| 아키텍처 개선 | (없음) | engineering/improve-codebase-architecture |
(없음) |
세 팩 동시 설치 시 어떤 게 자가 호출되는지는 description의 미세한 차이에 달려있다. Claude Code는 description 매칭 결과를 사용자에게 보여주지 않으므로, 충돌이 의심되면 비교해 보고 한쪽을 제거하는 게 빠르다.
4.2. Superpowers와 같이 깔면
Superpowers 리뷰 §4에서 다룬 다른 메타프레임과 섞을 때에 정확히 이 세 팩이 해당된다. 가장 자주 부딪치는 자리:
- Superpowers
test-driven-developmentvs Matttddvs Addytest-driven-development— 셋이 동시에 자가 호출 후보가 됨. - Superpowers
systematic-debuggingvs Mattdiagnosevs Addydebugging-and-error-recovery— 동일. - Superpowers
writing-skillsvs Mattwrite-a-skill— 동일.
→ 글로벌 CLAUDE.md에 어느 팩이 어느 영역을 가져가는지 한 줄로 못 박아 두는 게 사실상 유일한 해결 — 예컨대 디버깅은 systematic-debugging, TDD는 test-driven-development, Skill 작성은 writing-skills라고 우선순위를 명시하는 식.
4.3. Karpathy는 안 부딪힌다
karpathy-guidelines 1개는 동작 규약이라 슬래시·자가 호출·디시플린 게이트가 없다. 어떤 조합 위에도 그냥 얹을 수 있다 — 67줄짜리 행동 베이스라인으로만 작동.
5. 결론 — 누구 걸 깔까
세 팩의 결정 트리는 단순하다:
- 한 명만 깔 거면: Addy. 22개 X-driven development가 사실상 풀스택 디시플린 한 묶음이고, 프론트 특화 스킬까지 들어간다. 디시플린 게이트의 두께가 셋 중 가장 균형 잡혀 있다.
- 슬래시 워크플로가 필요하면: Matt를 골라서. 28개 다 깔 필요는 없고
engineering/{grill-with-docs,to-prd,to-issues,diagnose,zoom-out}+productivity/{caveman,handoff,grill-me}정도만. PRD·이슈 트래커가 첫 시민인 팀에서 가장 값어치 나옴. - 베이스라인: Karpathy. 어떤 조합 위에도 67줄짜리 동작 규약으로 얹는다. 충돌 위험 없음.
- Superpowers 위에 얹는 경우: Addy의 방법론 명사구는 Superpowers의 프로세스 게이트와 보완 관계 (전자는 왜 그렇게 짜야 하는지, 후자는 언제 어떤 단계로 짜야 하는지). Matt는 슬래시 ritual 영역만 골라서 —
to-prd·to-issues·triage·grill-with-docs·caveman5개 정도가 Superpowers와 안 겹치며 보완.