한 줄 요약
mattpocock/skills는 요구 질문, 프로젝트 용어 정리, 명세 작성, 테스트 같은 개발 습관을 필요한 단위로 꺼내 쓰는 스킬 모음입니다.
저장소: mattpocock/skills
에이전트가 코드를 빠르게 작성해도 정작 원하던 기능과 다르면 다시 설명해야 합니다. 저희 주간 AI 브리핑에서 소개한 이 저장소는 그런 요구 정렬과 개발 절차를 다룹니다. 팀에서 자주 반복되는 질문 하나, 자꾸 뜻이 엇갈리는 용어 하나부터 골라 적용해 보세요.
무엇을 할 수 있나
작고 고쳐 조합할 수 있는 스킬을 제공하며, 사용자가 직접 호출하는 스킬과 모델도 필요할 때 선택할 수 있는 스킬을 구분합니다. /grill-with-docs는 요구를 질문하면서 프로젝트 용어와 설계 결정을 문서화합니다. /to-spec는 대화를 명세로 정리하고, /tdd는 합의한 테스트 경계에서 실패하는 테스트와 최소 구현을 차례로 다룹니다.
팀에 필요한 것은 이름이 많은 스킬 목록보다 어떤 문제에서 어떤 스킬을 쓸지에 대한 기준입니다. 저희는 요구가 모호한 작업, 말이 엇갈리는 작업, 검증 기준이 필요한 작업을 나눠 살펴보시길 권합니다. 기존 팀 절차와 겹치는 부분도 함께 표시해 두세요.
설치와 초기 설정
Claude Code의 플러그인 설치 명령은 다음과 같습니다.
claude plugin install mattpocock-skills@claude-plugins-official
README에는 Codex 등 다른 에이전트의 설치 방법도 있습니다. 자동 갱신되는 플러그인과 편집 가능한 파일을 복사해 직접 갱신하는 skills.sh 방식 중 하나를 선택하세요. 같은 에이전트에 두 방식을 겹치면 스킬도 중복됩니다.
설치 후 저장소마다 다음 초기 설정을 진행합니다. 이슈 추적 도구, 분류 라벨, 생성 문서를 둘 위치를 정하는 단계입니다. 외부 도구를 연결할 때는 대상 프로젝트와 문서 공개 범위를 먼저 확인하세요.
/setup-matt-pocock-skills
활용 시나리오 1: 모호한 요구를 질문으로 좁히기
“관리자가 사용자를 관리할 수 있게 해 주세요”라는 요청에는 권한, 상태, 예외 조건이 빠져 있을 수 있습니다. 바로 구현을 맡기기보다 /grill-with-docs로 질문을 받아 보세요. 다음처럼 시작할 수 있습니다.
/grill-with-docs
관리자가 사용자 상태를 관리하는 기능을 계획하고 있습니다.
변경 가능한 상태, 승인 권한, 실패 시 동작을 먼저 질문해 주세요.
코드에서 확인할 수 있는 부분과 제가 결정할 부분을 나눠 주세요.
공식 가이드는 모호한 변경을 한 세션 안에서 정리하는 용도로 이 스킬을 안내합니다. 용어는 GLOSSARY.md에, 조건에 맞는 설계 결정은 docs/adr/에 기록합니다. 모든 답이 ADR이 되는 것은 아니므로, 꼭 지켜야 할 요구가 대화에만 남지 않았는지도 살펴보세요.
활용 시나리오 2: 팀 용어를 맞추고 명세로 이어가기
같은 “활성 사용자”를 기획자는 최근 접속한 사람으로, 개발자는 이용 가능한 계정으로 이해할 수 있습니다. 용어를 먼저 맞춘 뒤 같은 대화에서 /to-spec로 이어가 보세요. 공식 가이드도 질문에서 정리한 내용을 명세로 넘기는 흐름을 소개합니다.
/to-spec
방금 합의한 사용자 상태와 권한을 명세로 정리해 주세요.
정상 흐름, 거절해야 할 요청, 아직 결정하지 않은 조건을 구분하고,
게시하기 전에 대상 이슈 추적 도구와 프로젝트를 확인해 주세요.
명세를 받으면 질문에 답했던 조건과 한 줄씩 대조합니다. 특히 순서, 예외, 변경하지 않을 동작처럼 짧지만 중요한 조건이 빠지지 않았는지 확인하세요. 이 스킬은 이슈 추적 도구에 게시하는 역할도 하므로 비공개 요구를 어느 프로젝트에 남길지 주의해야 합니다.
활용 시나리오 3: 기능 하나를 관찰 가능한 테스트로 만들기
요구가 정해졌다면 테스트가 무엇을 확인해야 하는지도 정해 보세요. 공식 /tdd 가이드는 테스트를 쓸 경계를 먼저 합의하고, 실패하는 테스트 하나와 필요한 구현을 차례로 진행하는 방식을 설명합니다.
/tdd
빈 입력을 거절하고 정상 입력은 그대로 처리하는 동작을 검증하고 싶습니다.
먼저 관찰할 입력과 출력, 테스트 경계의 선택지를 설명해 주세요.
경계를 합의한 뒤 테스트 하나가 실패하는 이유부터 확인해 주세요.
실제 결과를 검토할 때는 테스트가 내부 함수 이름보다 사용자에게 보이는 동작을 확인하는지 살펴봅니다. 기대값이 명세에서 나온 것인지, 구현과 같은 계산을 반복한 것인지도 확인하세요. 테스트 수만 늘리기보다 어떤 요구를 검증했는지 읽을 수 있어야 합니다.
기업 도입에서 확인할 것
장점: 요구 정렬, 용어 정리, 검증 중 필요한 절차부터 선택할 수 있습니다. 요구 질문 가이드와 테스트 가이드를 팀의 현재 문제와 비교해 보세요.
운영 부담과 보안: 자동 갱신은 검토한 지침을 바꿀 수 있고, 직접 편집한 파일은 상위 변경을 관리할 담당자가 필요합니다. 설치 전에 기존 지침과의 충돌, 연결 도구, 게시 범위를 확인합니다. 스킬 문장과 실제 실행 권한도 구분하세요.
라이선스: 저장소는 MIT입니다. 수정·재배포 조건은 LICENSE에서, 에이전트와 이슈 서비스의 조건은 각 서비스에서 확인합니다.
원문과 함께 읽기
마치며
하이프마크 빌더 커뮤니티는 앞으로도 이렇게 직접 살펴본 AI 도구와 오픈소스를 꾸준히 공유하려고 합니다. 빌더 여러분께 도움이 될 좋은 자료들을 계속 모아 나누겠습니다.