에이전트에게 “알아서 하라”고 맡기면 결과물은 빨리 나오지만, 설계 합의·피드백 루프·도메인 언어가 비면 엔트로피도 같이 가속된다. 오늘 GitHub Trending 일간 목록에 오른 mattpocock/skills(약 28.1만 스타, 이 글 기준 오늘 +1,774)는 GSD·BMAD·Spec-Kit처럼 프로세스를 통째로 소유하지 않는다. 대신 작고 조합 가능한 스킬로 그릴링 → 스펙 → 태스크 그래프 → TDD → 이축 코드 리뷰 → 레트로까지를 조각내 제공한다. 이 글은 실무자 관점에서 저장소 구조, 호출 축, 메인 플로, implement-spec의 병렬 워크트리, 설치·버전 게이트, 대안 대비 트레이드오프를 해부한다.
한눈에 보는 프로젝트 현황
| 항목 | 확인한 값 (2026-10-09 KST) | 해석 |
|---|---|---|
| 저장소 | mattpocock/skills (주 언어 Shell, 실제 내용은 Markdown 스킬) |
실행 바이너리보다 SKILL.md와 플러그인 매니페스트가 본체 |
| 별 / 포크 | 281,246 / 23,568 (GitHub API) | Trending 페이지 ‘오늘 +1,774’. 같은 날 claude-mem은 +670 |
| 최신 릴리스 | v1.3.1 (2026-10-04 12:48 UTC → 10/4 21:48 KST) |
implement-spec·pr가 Engineering 버킷으로 졸업한 마이너 직후 패치 |
| 라이선스 | MIT (Copyright 2026 Matt Pocock) | 포크·사내 커스텀 스킬 파생이 자유롭다. 기여 게이트는 별도 |
| 패키지/플러그인 | mattpocock-skills 1.3.1, Claude Code 공식 마켓플레이스 등록 |
플러그인 자동 업데이트 vs skills.sh 복사본(수동 편집)을 둘 중 하나만 |
| 홈 | aihero.dev/skills, skills.sh 배지 | 문서·뉴스레터와 저장소가 한 제품처럼 묶여 있다 |
덧붙여 같은 날 오전 Opensource 심층 후보였던 thedotmack/claude-mem은 이미 MoricWorld에 게시된 글(슬러그 claude-mem-architecture-deep-dive-2026-10)이 있어 중복을 피하고, Trending에 실제로 남아 있는 AI 에이전트 툴링으로 이 저장소를 택했다.
설계 철학: 프로세스를 소유하지 않고, 조각을 조합한다
| 접근 | 무엇을 소유하나 | 실패 모드 | 이 저장소의 대응 |
|---|---|---|---|
| GSD / BMAD / Spec-Kit류 | 전체 워크플로·단계·산출물 형식 | 프로세스 버그가 나면 어디를 고쳐야 할지 불명, 통제권 상실 | 의도적으로 비대상. “프로세스를 뺏지 않는다”가 README 전제 |
| 거대 단일 프롬프트 / 메가 스킬 | 한 파일에 모든 규칙 | 토큰 낭비, 수정 비용 폭증, 라우팅 불가 | 스킬을 작고 조합 가능하게 유지. 신규 스킬 제안은 원칙적으로 거절 |
| mattpocock/skills | 재사용 가능한 규율(그릴링, TDD, 리뷰 축 등) | 사용자가 플로를 직접 짜야 함 | ask-matt가 라우터. 메인 플로·온램프·스탠드얼론을 문서화 |
README가 강조하는 네 가지 실패는 모두 “모델이 멍청해서”가 아니라 엔지니어링 피드백이 없어서다. (1) 요구가 흐릿하면 /grill-me·/grill-with-docs, (2) 용어가 안 맞으면 도메인 모델·GLOSSARY.md·ADR, (3) 코드가 안 돌면 /tdd·/diagnosing-bugs, (4) 진흙 공이 되면 /improve-codebase-architecture·/codebase-design. 스킬 세트는 이 네 축을 일상 호출 가능한 단위로 압축한 것이다.
저장소 구조와 플러그인 매니페스트
루트는 거의 문서·설정이다. 본체는 skills/ 아래 버킷이다.
| 경로 | 역할 | 운영 메모 |
|---|---|---|
skills/engineering/ |
일상 코딩 플로 (스펙·티켓·구현·리뷰·레트로) | 플러그인에 포함. ask-matt 라우팅 대상 |
skills/productivity/ |
그릴링 원시형, 핸드오프, teach, wait-what 등 | 코드 전용이 아닌 일반 워크플로 |
skills/in-progress/ |
실험 중 (chief-of-staff, claude-handoff, writing-* 등) | 졸업 전. 프로덕션 의존에 주의 |
skills/misc/ |
동결·비유지 (git-guardrails, shoehorn 마이그레이션 등) | 관련 이슈는 전부 닫힘 |
.claude-plugin/plugin.json |
이름·버전·스킬 경로 배열 | v1.3.1 기준 engineering+productivity 27개 경로 |
.out-of-scope/, SCOPE.md |
기여·신규 스킬 거절 사유 기록 | “관측된 실패 + 철학 적합” 이중 바 |
GLOSSARY.md |
Issue tracker / Issue / Decision ticket / Triage role | 스킬 간 용어 충돌을 먼저 막는 메타 레이어 |
각 스킬 디렉터리는 최소 SKILL.md(YAML frontmatter + 본문)를 갖고, Codex/OpenAI 계열을 위해 agents/openai.yaml을 두는 경우가 많다. user-invoked 스킬은 frontmatter에 disable-model-invocation: true를 켜 모델이 勝手 호출하지 못하게 한다. Codex 쪽은 policy.allow_implicit_invocation: false로 같은 축을 표현한다.
---
name: implement-spec
description: "Implement the result of /to-spec and /to-tickets in code."
disable-model-invocation: true
---
# (본문: 태스크 그래프 → 워크트리 구현자 → merger → code-review)호출 축과 idea → ship 메인 플로
ask-matt는 이 저장소의 라우팅 맵이다. 핵심 구분은 둘이다. User-invoked는 오케스트레이션(당신이 타이핑해야 함). Model-invoked는 재사용 규율(모델이 상황에 맞게 집어 들 수 있음). user-invoked가 model-invoked를 부를 수는 있어도, user-invoked끼리 서로 부르지는 않는다.
| 단계 | 스킬 | 산출 | 컨텍스트 위생 |
|---|---|---|---|
| 1. 합의 | /grill-with-docs (또는 무저장 /grill-me) |
GLOSSARY.md·ADR 갱신, 설계 트리 해소 |
워킹 디렉터리가 있으면 문서 남기는 쪽을 기본 |
| 2. 검증 우회 | /handoff ↔ /prototype |
던질 수 있는 프로토타입, 학습을 원 스레드로 환승 | 프로토타입은 별 디렉터리/브랜치가 전제 |
| 3a. 다세션 | /to-spec → /to-tickets → /implement 또는 /implement-spec |
스펙, 블로킹 엣지가 있는 티켓, 통합 브랜치 | 그릴링~티켓까지는 한 창. 구현은 티켓마다 fresh |
| 3b. 단세션 | 같은 창에서 /implement |
즉시 TDD+리뷰 | 스마트 존(~150k) 안에서만 |
| 4. 마무리 | /pr(모델), /retro(유저) |
시각 요약 PR, 환경(체크·스티어링) 개선안 | 레트로는 세션을 비우기 전에 |
온램프도 명시적이다. 들어온 이슈 더미는 /triage(단, /to-tickets가 만든 티켓은 다시 트리아지하지 않음). 고집 센 버그는 /diagnosing-bugs. 한 세션에 안 담기는 안개는 /wayfinder로 결정 티켓 맵을 그린 뒤, 빌드는 /to-spec으로 합쳐 메인 플로에 합류한다. wayfinder 맵을 바로 /implement에 넣으면 연결된 결정 디테일이 날아간다고 문서가 경고한다.
grilling 프론티어와 to-tickets 태스크 그래프
/grilling은 인터뷰 원시형이다. 설계를 트리로 보고, 전제조건이 이미 해소된 질문만 frontier로 모아 한 라운드에 전부 묻는다. 각 질문에는 추천 답을 붙이고, “yes”가 추천 수락이 되도록 문장을 쓴다. 사실(파일시스템·도구로 알 수 있는 것)은 서브에이전트에게 맡기고 사용자에게 묻지 않는다. 결정은 사용자에게만 맡긴다. 프론티어가 비면 합의 완료.
/to-tickets는 그 합의를 tracer-bullet 수직 슬라이스로 쪼갠다. 각 티켓은 스키마·API·UI·테스트를 얇게 관통해야 하고, 단독으로 데모/검증 가능해야 하며, 한 번의 fresh 컨텍스트에 들어가야 한다. 블로킹 엣지를 선언해 그래프를 만들고, “지금 잡을 수 있는 것”이 다시 frontier가 된다. wide refactor만 예외로 expand–contract 시퀀스를 허용한다.
| 트래커 | 티켓 형태 | 블로킹 표현 | 기본 라벨 |
|---|---|---|---|
| 로컬 파일 | .scratch/<feature>/issues/<NN>-<slug>.md 티켓당 1파일 |
본문 “Blocked by”에 번호/제목 | ready-for-agent 상태 텍스트 |
| GitHub / Linear 등 | 이슈 1개 = 티켓 1개 (블로커 먼저 생성) | 네이티브 blocking 링크 또는 본문 참조 | 트리아지 맵의 ready-for-agent |
implement-spec: 병렬 워크트리 오케스트레이션
v1.3.x의 하이라이트는 /implement-spec이다. 목표는 PR이 아니라 통합 브랜치에 스펙 전체다. 초안 PR은 트래커가 PR로 이슈를 닫을 때, 또는 사용자가 요청할 때만, 그리고 첫 머지 이후(커밋 없는 브랜치는 PR을 못 염)에 연다.
- 스펙·티켓을 읽어 태스크 그래프 파악
- (선택) exploration 서브에이전트가 리포 밖 노트 디렉터리에 조사 결과 저장 — 구현자가 탐색에 시간 쓰지 않게
- 통합 브랜치 생성
- 각 티켓 = 구현자 서브에이전트 = 자체 worktree/branch. 시작 전 통합 브랜치 기반 확인,
tdd로 빌드, 완료 전 통합 tip을 자기 브랜치에 머지 - 완료 시 merger 서브에이전트가 통합 브랜치로 머지 → frontier 갱신 → 가능한 티켓을 또 띄움
- 전부 끝나면 통합 브랜치에
code-review한 번, 이슈는 단일 구현자로 수정 - 워크트리 정리
통신은 희소하다. 스펙·티켓·리서치 노트·이전 커밋에 대한 컨텍스트 포인터를 우선하고, 이미 있는 정보를 복제하지 말라고 명시한다. 이건 멀티에이전트 토큰 폭주를 막는 운영 규칙이다 설계 결정이다.
/code-review는 이축이다. Standards(레포 코딩 표준 + Fowler 냄새 베이스라인)와 Spec(원 이슈/스펙 충실도)을 병렬 서브에이전트로 돌려 서로 오염시키지 않는다. /tdd는 red-green-refactor와 “좋은/나쁜 테스트” 가이드를 제공하고, /pr은 본문을 “변화를 드러내는 최소 시각물 + before/after 증거 + one-way/two-way door·blast radius”로 강제한다.
설치·버전·이 박스에서의 한계
| 경로 | 명령/방식 | 업데이트 | 주의 |
|---|---|---|---|
| Claude Code | claude plugin install mattpocock-skills@claude-plugins-official |
기본 자동 | 공식 마켓 경로 |
| Codex | marketplace add → mattpocock-skills@mattpocock |
시작 시 | openai.yaml 정책 확인 |
| GitHub Copilot | marketplace + extraKnownMarketplaces |
autoUpdate 설정 | VS Code Chat: Install Plugin From Source도 가능 |
| skills.sh 복사 | 프로젝트에 편집 가능한 파일 복사 | 수동 | 플러그인과 동시 설치 시 스킬이 이중으로 생김 — README가 둘 중 하나만 하라고 함 |
| 기타 하네스 | Amp, Cursor, OpenCode, Pi, Trae, Droid, Kiro 등 README에 설치 블록 | 제품별 | 공통 전제: 에이전트 스킬/플러그인 로더 |
# 레포당 1회: 이슈 트래커·트리아지 라벨·도메인 문서 레이아웃
# (Claude Code 등에서)
/setup-matt-pocock-skills
# 상황 라우팅
/ask-matt
# 다세션 빌드 골격
/grill-with-docs
/to-spec
/to-tickets
/implement-spec이 글을 쓴 Linux 박스에서는 GitHub API·raw 파일·플러그인 JSON·주요 SKILL.md를 검증했다. Claude Code/Codex UI에 플러그인을 실제로 설치해 세션을 돌리지는 않았다(대화형 IDE·구독 로그인 부재). 따라서 “설치 명령이 문서에 있다”는 수준까지가 박스 검증 범위고, worktree 병렬 구현·트리아지 라벨 매핑은 문서·릴리스 노트 기준이다. 원 후보 claude-mem과 달리 Node 런타임 버전 게이트는 없다. 의존성은 사실상 마크다운과 호스트 에이전트다.
대안 대비 트레이드오프
| 비교 대상 | 강점 | 이 저장소가 이기는 지점 | 질 수 있는 지점 |
|---|---|---|---|
| GSD / BMAD / Spec-Kit | 처음부터 끝까지 한 레시피 | 조각 수정·포크·스킬 단위 교체 용이 | 초보 팀이 “무엇을 언제”를 스스로 고르기 어려움 |
| anthropics/knowledge-work-plugins | 역할별(영업·재무·PM) MCP 커넥터 번들 | 소프트웨어 엔지니어링 규율·티켓 그래프에 특화 | 비엔지니어링 지식노동·엔터프라이즈 커넥터 |
| cathrynlavery/diagram-design | 다이어그램 산출물 품질 | 빌드·리뷰·레트로 전 주기 | 시각 산출물 전문성 |
| 자체 CLAUDE.md / AGENTS.md만 | 레포 특화, 가벼움 | 검증된 플로·호출 축·기여 게이트가 이미 정리됨 | 팀 고유 프로세스에 맞추려면 결국 포크/skills.sh 편집 |
기여 게이트와 운영 함정
SCOPE.md의 바는 단순하다. (1) 실제 세션에서 관측된 실패를 서술할 것, (2) .out-of-scope/와 철학에 맞을 것. 가설적 “있으면 좋겠다”는 닫힌다. 신규 스킬 제안·기여는 명시적으로 거절된다. 이유는 유지비다. 스킬 하나마다 ask-matt 맵·문서 페이지·플러그인 매니페스트를 같이 맞춰야 한다. 기존 스킬로 조합 가능하면 새 스킬을 만들지 말라고 한다. 사내 전용 플로는 포크나 skills.sh 복사본에 두라는 메시지다.
실무에서 자주 걸릴 함정만 짚으면 다음과 같다.
- 플러그인 + skills.sh 이중 설치 → 같은 스킬이 두 번 로드된다.
- setup을 건너뜀 → engineering 스킬이 이슈 트래커를 못 찾아 setup을 요구한다.
- to-tickets 산출을 다시 triage → 이미 agent-ready인데 상태가 꼬인다.
- wayfinder 맵을 바로 implement → 결정 그래프가 빌드 단위로 붕괴되지 않은 채 들어간다.
- 스마트 존을 넘긴 채 그릴링~티켓을 한 창에 유지 → 문서가 권하는 건 phase boundary에서 compact이지, 열화된 창에서 밀어붙이는 것이 아니다.
- misc/in-progress 의존 → 동결·실험 버킷이다.
정리
mattpocock/skills는 “에이전트에게 더 긴 시스템 프롬프트를 준다”는 접근이 아니다. 호출 권한(user vs model), 컨텍스트 위생(언제 clear/handoff/subagent/compact할지), 작업 분해(수직 슬라이스 + 블로킹 그래프), 피드백(TDD·이축 리뷰·레트로로 환경 개선)을 스킬 단위 인터페이스로 고정한다. v1.3.1의 implement-spec은 그 그래프를 병렬 워크트리로 실행하는 오케스트레이터다. 프로세스를 통째로 사고 싶지 않은 팀, 이미 이슈 트래커와 테스트 문화가 있는 팀에 맞고, “버튼 하나로 전 주기”를 원하는 팀에는 의도적으로 비어 있다. 그 빈자리가 이 저장소의 제품 경계다.