Matt Pocock skills의 설치 명령은 짧다. 하지만 이 묶음의 쓸모는 코딩 에이전트에게 명령 몇 개를 더 주는 데 있지 않다. 같은 저장소에서 사람과 에이전트가 반복해서 일할 때, 이슈는 어디에 만들고, 어떤 상태 이름을 쓰며, 프로젝트 용어와 과거 결정은 어디서 읽을지를 고정하는 데 있다.
설정이 없으면 에이전트는 매 작업마다 이슈 트래커와 문서 위치를 다시 찾거나, 없는 라벨을 만들고, 이미 정한 용어와 다른 이름으로 요구사항을 쓸 수 있다. Matt Pocock skills는 이 반복을 줄이는 작업 흐름이다. 설치 전에 자신에게 필요한 흐름인지부터 보는 편이 낫다.
설치 전에: 다음 작업에서 무엇이 달라지는가
이 스킬 묶음은 한 번의 답변이나 한 번의 코드 생성을 더 잘하게 만드는 도구가 아니다. 요구사항을 다듬고, 실행 가능한 작업으로 나누고, 이슈 상태와 프로젝트 언어를 이어 붙이는 역할을 나눈다. 가장 먼저 실행하는 /setup-matt-pocock-skills는 저장소별로 이 세 가지를 묻는다.
| 정할 것 | 이후에 쓰는 스킬 | 실제로 줄어드는 혼선 |
|---|---|---|
| 이슈를 둘 곳과 외부 PR 처리 여부 | /to-issues, /triage | 에이전트가 GitHub 이슈, 로컬 마크다운, 다른 트래커 중 어디에 기록할지 추측하지 않는다. |
| 상태 라벨의 실제 이름 | /triage | needs-triage, ready-for-agent 같은 흐름을 저장소의 기존 라벨과 맞춰 쓴다. |
| 용어집과 ADR의 위치 | /grill-with-docs, /tdd | 새 계획과 테스트가 이미 정한 도메인 용어, 되돌리기 어려운 결정을 건너뛰지 않는다. |
핵심은 문서를 많이 만드는 일이 아니다. 예를 들어 주문 상태를 바꾸는 기능을 논의할 때, "취소"가 주문 전체 취소인지 일부 품목 취소인지 먼저 정해 두면 다음 에이전트가 다른 뜻으로 API와 테스트를 만들 가능성이 줄어든다. /grill-with-docs는 이런 모호한 말을 질문으로 좁히고, 필요하면 용어집과 ADR에 남기는 흐름이다.
하나의 요청을 실제 작업으로 바꾸는 흐름
새 기능 요청이 들어왔을 때 바로 코드를 쓰지 않는 팀이라면 다음 조합이 유용하다.
- 요구사항을 먼저 좁힌다.
/grill-me는 빠진 결정과 충돌하는 조건을 질문한다. 결정과 용어까지 남겨야 하면/grill-with-docs를 쓴다. - 완성 가능한 단위로 나눈다.
/to-issues는 데이터베이스, API, 화면을 따로 떼어낸 작업 목록 대신, 한 항목만 끝내도 검증 가능한 세로 작업 단위로 나눈다. 의존성이 있으면 먼저 끝나야 할 작업도 적는다. - 들어온 이슈를 같은 기준으로 정리한다.
/triage는 버그와 개선을 구분하고, 추가 정보가 필요한지, 에이전트가 바로 맡을 수 있는지, 사람이 판단해야 하는지를 상태 라벨로 남긴다. - 구현은 이미 정한 언어를 읽고 시작한다.
/tdd는CONTEXT.md와 ADR을 읽고, 내부 함수가 아니라 사용자가 보게 되는 동작을 테스트 이름과 기준으로 삼도록 요구한다.
이 순서가 항상 필요한 것은 아니다. 한 파일의 오타를 고치거나, 한 번만 쓸 개인 스크립트를 만드는 일이라면 설치와 설정에 드는 시간이 더 크다. 반대로 여러 사람이 같은 제품을 다루거나, 에이전트가 이슈를 반복해서 만들고 구현하는 저장소라면 첫 설정의 효용이 누적된다.
어떤 경우에 설치할 만한가
| 상황 | Matt Pocock skills가 맞는 이유 |
|---|---|
| 기능 요청은 많은데 시작 전에 결정이 자주 빠진다 | 질문과 용어 정리 단계를 코드 작성보다 앞에 둔다. |
| 이슈가 큰 작업 묶음으로만 쌓여 에이전트에게 넘기기 어렵다 | /to-issues가 끝까지 검증 가능한 작은 작업 단위를 제안한다. |
| 사람과 에이전트가 서로 다른 용어와 라벨을 쓴다 | 저장소별 트래커, 라벨, 문서 위치를 한 번 정하고 이후 스킬이 그 설정을 읽는다. |
| 이미 이슈 관리와 의사결정 기록이 안정적으로 굴러간다 | 기존 규칙을 대체하기보다 라벨과 문서 위치를 연결해 쓰는 편이 낫다. |
반대로 코드 자동완성이나 에이전트의 모델 성능을 기대하고 설치하면 맞지 않는다. 이 스킬들은 모델을 바꾸지 않는다. 작업을 넘기기 전에 사람이 확인할 질문과, 다음 사람이 찾아볼 기록을 남기는 쪽에 가깝다.
설치는 두 경로 중 하나만 고른다
Claude Code만 쓰고 제작자가 갱신하는 전체 묶음을 그대로 받고 싶다면 관리형 플러그인 경로가 맞다.
claude plugins install mattpocock-skills
Codex를 쓰거나, 선택한 스킬 파일을 프로젝트 안에 두고 직접 조정하려면 skills.sh 경로를 쓴다.
npx skills@latest add mattpocock/skills
두 경로는 같은 저장소에 겹쳐 설치하지 않는다. 공식 README는 스킬이 중복될 수 있다고 안내한다. 관리형 업데이트가 필요한지, 프로젝트별로 파일을 편집해야 하는지를 기준으로 하나만 고른다.
설치 직후에 한 번 할 일
설치가 끝나면 /setup-matt-pocock-skills를 실행한다. 이 단계는 코드를 생성하지 않는다. 이슈 트래커, 다섯 가지 triage 상태를 가리키는 실제 라벨, 도메인 문서의 단일 또는 다중 구조를 차례로 정한다. 결과는 사용 중인 AGENTS.md 또는 CLAUDE.md와 docs/agents/ 아래 설정 문서에 남는다.
여기서 중요한 선택은 "GitHub가 기본값이니 그대로 쓴다"가 아니다. 지금 팀이 실제로 이슈를 기록하는 곳을 고르는 일이다. GitHub나 GitLab을 쓴다면 외부 PR도 요청으로 분류할지 정하고, 개인 프로젝트라면 로컬 마크다운을 택할 수 있다. 이 선택을 한 번 남겨 두어야 /triage와 /to-issues가 다음 번에 엉뚱한 곳에 기록하지 않는다.
실패하기 쉬운 사용법
설치만 하고 바로 코드 생성으로 돌아가는 경우
이 경우 스킬 묶음은 명령 목록으로 끝난다. 실제로 효용을 보려면 다음 기능 요청에서 /grill-with-docs로 모호한 말을 정리하거나, 이미 합의한 계획을 /to-issues로 나누는 한 번의 사용까지 이어져야 한다.
모든 일을 인터뷰로 시작하는 경우
작은 수정까지 길게 질문하면 흐름이 무거워진다. 요구사항이 이미 명확한 버그 수정이나 한 번짜리 작업에는 바로 구현하는 편이 낫다. 이 스킬은 결정 비용이 큰 작업에만 꺼내는 도구다.
선택 설치에서 필요한 짝을 빼먹는 경우
공식 이슈 #475에는 /grill-me만 골랐을 때 그 안에서 쓰는 grilling이 빠질 수 있다는 보고가 있다. 설치기에서 의존 스킬도 함께 선택한다. Node.js의 styleText 오류나 Claude Code 플러그인 탐색 오류는 공식 이슈 #523, #726의 해결 순서를 확인한다.
설치가 아니라 다음 행동까지 확인하기
- skills.sh 경로라면
npx skills list로 설치 목록을 확인한다. - 선택 설치라면 대상 에이전트의 스킬 경로에
SKILL.md가 생겼는지 확인한다. /setup-matt-pocock-skills를 실행해 트래커, 라벨, 문서 구조를 고르는 대화가 시작되는지 확인한다.- 다음 기능 요청 하나에서
/grill-with-docs또는/to-issues를 실제로 실행해, 저장소의 용어와 설정을 읽는지 확인한다.
이 마지막 단계까지 해 봐야 설치가 팀의 작업 방식에 맞는지 판단할 수 있다. 반복되는 프로젝트 맥락을 정리할 필요가 없다면, 스킬을 많이 설치하지 않는 쪽이 더 낫다.
출처: mattpocock/skills 공식 README, setup-matt-pocock-skills 공식 문서, engineering skills 공식 목록, 공식 이슈 #475, 공식 이슈 #523, 공식 이슈 #726 (2026-09-01 확인)