Total TypeScript로 유명한 Matt Pocock 씨가 자신의 .claude 디렉토리에서 추출한 스킬 모음인 mattpocock/skills를 공개하고 있습니다.

/grill-me(구현 전에 AI가 인간을 "심문"하여 계획을 확고히 하는 스킬)가 X에서 화제가 된 것을 계기로, 리포지토리는 2026년 2월 공개 이후 5개월 만에 157K star / 13.5K fork(2026-07-05 시점)까지 성장했습니다.

저도 이 리포지토리의 스킬 세트를 도입했기에, 전체적인 모습, 설계 사상, 주요 스킬을 정리해 보겠습니다.

참고로 이 기사는 skills를 이미 사용하고 있는 분들을 대상으로 합니다. skills의 메커니즘 자체(SKILL.md 작성법이나 배치 장소)에 대해서는 다루지 않습니다.

38개의 스킬이 6개의 버킷(bucket)으로 정리되어 있습니다.

버킷	수	내용
engineering	16	코드 작업에서 매일 사용하는 것 (tdd, code-review, to-prd 등)
...

안정적인 버킷은 위의 4개로 총 27개 스킬입니다. in-progress와 deprecated가 별도로 public에 남아 있는 것이 특징이며, 스킬이 어떻게 진화하고 도태되어 왔는지 추적할 수 있습니다. 예를 들어 deprecated에는 용어집 추출인 ubiquitous-language가 잠들어 있지만, 그 역할은 현재 engineering의 domain-modeling이 담당하고 있어 설계의 변천사를 읽을 수 있습니다.

README 서두에는 이 리포지토리의 위치가 적혀 있습니다. GSD·BMAD·Spec-Kit과 같이 "개발 프로세스 자체를 관리하는" 접근 방식은 프로세스 도중에 문제가 발생했을 때 수정하기 어렵습니다. 반면 이 스킬군은 작고, 개조하기 쉬우며, 조합 가능하게 만든다는 사상을 가지고 있습니다.

구조 측면에서 흥미로운 점은 모든 스킬이 user-invoked / model-invoked 두 종류로 분류되어 있다는 것입니다.

• user-invoked: 인간이 /grill-me와 같이 명시적으로 호출하는 것. 역할은 오케스트레이션 (orchestration)
• model-invoked: 태스크에 적합하다면 에이전트가 자발적으로 사용해도 되는 것. 재사용 가능한 "규율"을 유지함

그리고 "user-invoked 스킬은 model-invoked 스킬을 호출할 수 있지만, 다른 user-invoked 스킬을 호출해서는 안 된다"라는 규칙이 세워져 있습니다. 엔트리 포인트(entry point)와 부품이 명확하게 분리되어 있는 것입니다.

예를 들어 화제가 된 grill-me 본체는 실질적으로 이것뿐입니다.

---
name: grill-me
description: A relentless interview to sharpen a plan or design.
...

심문 로직의 실체는 model-invoked인 grilling에 있으며, grill-me는 그 입구에 불과합니다. 후술할 grill-with-docs도 동일한 grilling을 호출하는 또 다른 입구입니다. 이 "얇은 입구 + 공유 부품" 패턴은 직접 스킬을 만들 때 늘어나는 정리법으로서 그대로 모방할 수 있습니다.

README 자체가 "AI 에이전트의 전형적인 실패 모드별"로 구성되어 있으므로, 그에 따라 주요 스킬을 소개합니다.

가장 빈번한 실패는 의도의 불일치입니다. The Pragmatic Programmer의 "No-one knows exactly what they want"가 인용되어 있습니다.

/grill-me는 구현에 들어가기 전에 AI가 인간에게 질문 공세를 퍼붓는 스킬입니다. 포인트는 3가지입니다.

• 질문은 반드시 한 번에 하나씩. 한꺼번에 묻지 않는다.
• 각 질문에 AI 자신의 권장안을 붙인다. 인간은 Yes/No 또는 수정 사항만 답하면 된다.
• 코드베이스를 읽으면 알 수 있는 질문은 인간에게 묻지 않고 코드를 읽어서 해결한다.

그리고 "합의에 도달했다고 인간이 확인할 때까지 구현하지 않는다"라고 명시되어 있습니다.

/grill-with-docs는 동일한 심문에 domain-modeling(후술)을 결합한 것으로, 심문의 부산물로서 ADR과 용어집이 리포지토리에 쌓이게 됩니다. 코드 작업이라면 이쪽을, 그 외(문장 구성, 기획 만들기 등)라면 grill-me를 사용하는 식으로 구분하여 사용합니다.

프로젝트 고유의 개념에 이름이 붙어 있지 않으면, 에이전트는 한 단어로 끝낼 수 있는 것을 20단어로 설명하기 시작합니다. 이에 대한 처방전이 바로 **공유 언어 (Shared Language)**이며, domain-modeling 스킬이 이를 담당합니다.

이 스킬은 용어집인 CONTEXT.md와 ADR (Architecture Decision Records)을 관리합니다. README에 나와 있는 Matt 본인의 리포지토리 예시가 이해하기 쉽습니다.

• Before: "코스의 섹션 내 레슨이 '실체화(materialized)'될 때(파일 시스템상의 위치를 부여받을 때) 문제가 있다"
• After: "materialization cascade에 문제가 있다"

한번 CONTEXT.md에 정의된 용어는 변수명, 파일명, 대화의 모든 곳에서 일관되게 사용되도록 하며, 코드베이스 네비게이션도 훨씬 수월해집니다.

ADR의 경우, "비가역적이고, 문맥 없이는 이해할 수 없으며, 진정한 트레이드오프(trade-off)의 결과"라는 3가지 조건이 모두 충족될 때만 작성하도록 제한되어 있다는 점이 실용적입니다. 무엇이든 ADR로 만들면 아무도 읽지 않게 된다는 경험칙이 반영되어 있습니다.

의도가 맞더라도 출력이 좋지 않다면 피드백 루프를 의심하라는 장입니다.

/tdd는 red-green-refactor 루프를 돌리는 스킬이지만, 독특한 점은 **seam (봉제선/경계)**을 다루는 방식입니다. 테스트를 작성할 경계(공개 인터페이스)를 구현 전에 인간과 합의하며, 합의되지 않은 seam에는 테스트를 작성하지 않는다는 규칙이 있습니다. 이는 테스트 공수를 중요한 경로에 집중시키기 위한 메커니즘입니다. 그 외에도 "tautological test (구현과 동일한 계산으로 기대값을 만들어 절대 실패하지 않는 테스트)"와 같은 안티 패턴 모음이 동봉되어 있어, 테스트 방침을 위한 문서로서 단독으로 읽을 가치도 충분합니다.

/diagnosing-bugs는 까다로운 버그를 위한 진단 루프로, reproduce → minimise → hypothesise → instrument → fix → regression-test라는 절차를 강제합니다. "일단 수정해 보자"라는 식의 접근을 억제합니다.

에이전트는 코딩을 가속하는 만큼, 소프트웨어의 엔트로피 증가도 가속화한다는 문제 의식을 가지고 있습니다.

codebase-design은 A Philosophy of Software Design의 deep module (작은 인터페이스 뒤에 많은 기능을 숨기는 것) 어휘를 각 스킬에 공급하는 부품이며, improve-codebase-architecture는 코드베이스를 스캔하여 "심화시킬 수 있는 부분"을 HTML 리포트로 제시하고, 선택된 항목을 심문 형식으로 파고드는 user-invoked 스킬입니다. Matt은 며칠에 한 번씩 이를 실행할 것을 권장합니다.

개별 스킬과는 별개로, 계획부터 구현까지 일관되게 이어지는 흐름이 준비되어 있습니다.

/grill-with-docs (심문을 통해 계획을 공고히 함)
↓
/to-prd (대화 내용을 그대로 PRD로 변환하여 issue tracker에 발행)
...

• /to-prd의 포인트는 인터뷰를 하지 않는다는 점입니다. 심문은 grill-with-docs에서 이미 끝났다는 전제하에, 대화 내용을 단순히 PRD로 합성합니다 (유일하게 테스트를 작성할 경계인 seam에 대한 가정만 인간에게 확인을 받습니다).
• /to-issues는 tracer bullet 방식으로, 1 issue = 스키마부터 UI, 테스트까지 관통하는 얇은 수직 절단(vertical slice)으로 만듭니다. 단독으로 데모 가능한 입도(granularity)를 가집니다.
• /implement의 내용은 몇 줄 되지 않으며, /tdd와 /code-review에 위임합니다. /code-review는 Standards (리포지토리의 코딩 규약을 따르는가)와 Spec (원래 issue의 요구사항을 충족하는가)이라는 두 축을 병렬적인 서브 에이전트가 리뷰하는 구성입니다.

이 워크플로우 계열 스킬을 사용할 경우에는 리포지토리마다 /setup-matt-pocock-skills를 한 번 실행하여 issue tracker (GitHub / GitLab / 로컬 markdown)와 triage 레이블을 설정해 두어야 합니다.

여기까지 언급하지 않은 안정적인 버킷(stable bucket)의 스킬들입니다.

스킬	한 줄 설명
ask-matt	"현재 상황에서 어떤 스킬이 필요할까?"라고 답해주는 라우터
...

개발 중인 버킷(development bucket) 중에서, 현재 Matt님이 가장 공을 들이고 있는 것이 wayfinder입니다.

1 세션에 담기 어려운 큰 작업을 issue tracker 상의 "지도"로서 관리하는 오케스트레이터(orchestrator)로, 아직 언어화되지 않은 영역을 "전장의 안개 (fog of war)"로 명시적으로 남겨두고, 조사 티켓을 1 세션당 1장씩 해결할 때마다 안개가 걷히며 새로운 티켓이 생겨나는 설계로 되어 있습니다.

Matt님 스스로가 "grill-me의 다음 진화형"이라고 정의하고 있으며, 코스 제작 전체를 이것으로 계획하고 있다고 합니다. 다만 in-progress, 즉 파괴적 변경(breaking change)을 전제로 하는 버킷에 있으므로, 이 기사에서는 깊게 다루지 않겠습니다. 안정 버킷(stable bucket)으로 승격되면 다시 작성하고 싶습니다.

skills.sh의 설치 프로그램이 준비되어 있습니다.

npx skills@latest add mattpocock/skills

대화형으로 "어떤 스킬을" "어떤 에이전트 (Claude Code / Codex / Cursor 등)에" 넣을지 선택할 수 있습니다.

한 가지 주의할 점이 있습니다. 앞서 언급했듯이 스킬 간에 호출 관계가 있으므로, 일부만 골라서 설치하면 의존성(dependency)이 끊어집니다. 주요 의존 관계는 다음과 같습니다.

스킬	의존 대상
grill-me	grilling
...

고민된다면 "사용하고 싶은 user-invoked 스킬 + model-invoked 세트"로 설치해 두는 것이 안전합니다.

• mattpocock/skills는 "프로세스를 통째로 넘기지 않고, 작은 부품들을 조합한다"는 사상을 가진 스킬 모음입니다. user-invoked / model-invoked의 분리는 직접 스킬을 만들 때 정리하는 방법으로서도 참고가 됩니다.
• 입문용으로는
  /grill-me

단독 사용을 추천합니다. 계획이 있는 모든 작업에 사용할 수 있습니다. - 마음에 든다면
/grill-with-docs

로 가보세요. ADR(Architecture Decision Record)과 용어집이 쌓이기 시작합니다. - issue tracker 운영까지 깊게 들어가고 싶다면
/setup-matt-pocock-skills

• to-prd → to-issues → implement의 풀 워크플로우(full workflow)를 사용하세요. - 스킬은 작게 개조하는 것을 전제로 작성되어 있으므로, 포크(fork)하여 자신의 환경에 맞춰 사용하세요.