2026-06-01 - Matt Pocock - Skills For Real Engineers

Source

• 저자: Matt Pocock
• 유형: GitHub 저장소 (에이전트 skill 모음)
• URL: mattpocock/skills @ aaf2453
• 확인일: 2026-06-01 (main 브랜치 커밋 aaf2453)
• 성격: 저자 본인의 저장소다. 실무자 한 명의 운영 경험에서 나온 절차이고, 효과를 정량으로 검증한 자료는 없다.

TL;DR

• Claude Code, Codex 같은 코딩 에이전트의 반복 실패를 줄이려고 엔지니어링 절차를 작은 skill 단위로 묶은 저장소다.
• 저자가 강조하는 것은 한 줄 프롬프트의 품질보다 에이전트가 같은 엔지니어링 절차를 반복하게 만드는 작업 흐름이다.
• 공개된 skill은 engineering 10개, productivity 4개, misc 4개이며, 요구사항 정렬·문서화·작업 분해·테스트·아키텍처 개선을 각각 별도 루프로 나눈다.
• issue tracker, CONTEXT.md, ADR, 테스트 체계를 갖춘 저장소에 적용하기 쉽고, 검증 루프가 없는 코드베이스에서는 skill만으로 품질을 담보하기 어렵다.

문제 설정과 설계 원칙

Pocock은 코딩 에이전트가 자주 실패하는 원인으로 요구사항 어긋남, 공유 언어 부재, 피드백 루프 부재, 코드베이스 엔트로피 증가를 든다.

대응 수단으로 제시하는 것이 skill이다. 특정 작업 절차를 작고 조합 가능한 SKILL.md 단위로 에이전트에게 주입하고, slash command로 불러 쓴다. 저자는 프롬프트 하나보다 저장소 문서, issue tracker, 테스트, ADR, 인수인계 문서 같은 외부 산출물과 skill이 맞물릴 때 결과가 안정된다고 본다.

공개된 스킬

Engineering

Skill	역할	해석
setup-matt-pocock-skills	저장소별 skill 초기 설정	issue tracker, triage 라벨 어휘, 도메인 문서 위치를 AGENTS.md/CLAUDE.md와 docs/agents/에 고정한다.
grill-with-docs	CONTEXT.md, ADR을 보면서 질문	도메인 언어와 결정 기록을 작업 중 갱신한다.
to-prd	대화 맥락을 PRD로 전환	합의를 issue tracker에 올릴 수 있는 명세로 고정한다.
to-issues	PRD·계획을 기능 단위 이슈로 분해	작업을 처음부터 끝까지 검증할 수 있는 티켓 단위로 자른다.
triage	issue 선별	들어온 issue가 에이전트가 바로 처리할 수 있는 일인지, 사람이 먼저 정보를 보충하거나 판단해야 하는 일인지 나눈다.
tdd	red-green-refactor 루프	공개 인터페이스 기준의 테스트를 피드백 루프로 쓴다.
diagnose	재현, 최소화, 가설, 계측, 수정, 회귀 테스트	즉흥 수정 대신 정해진 진단 순서로 디버깅한다.
improve-codebase-architecture	모듈을 깊게 만들 지점 탐색	얕은 모듈과 결합도를 찾아 테스트하기 쉽고 에이전트가 탐색하기 쉬운 구조로 바꾼다.
zoom-out	코드의 상위 맥락 설명	낯선 코드 영역을 시스템 전체 관점에서 이해하게 해 탐색 비용을 줄인다.
prototype	버릴 프로토타입 작성	상태·비즈니스 로직이나 UI 변형을 빠르게 실험해 설계 결정을 좁힌다.

Productivity

Skill	역할	해석
caveman	초압축 커뮤니케이션	장황한 응답을 줄여 토큰 비용과 소통 부담을 낮춘다.
grill-me	코드 밖 계획 인터뷰	코드가 아닌 계획·디자인도 결정 트리 방식으로 캐묻는다.
handoff	세션 인수인계	컨텍스트 창이 끊긴 뒤에도 작업 상태를 이어받게 한다.
write-a-skill	새 skill 작성	점진적 공개(progressive disclosure)와 skill 구조 규칙에 맞춰 새 skill을 만든다.

Misc

Skill	역할	해석
git-guardrails-claude-code	위험한 git 명령 차단 hook	push, reset --hard, clean 등을 막는 Claude Code hook을 설정한다.
migrate-to-shoehorn	TypeScript 테스트 단언 이전	테스트 파일의 as 타입 단언을 @total-typescript/shoehorn 기반으로 옮긴다.
scaffold-exercises	교육용 연습문제 구조 생성	섹션, 문제, 해설, 솔루션 디렉터리를 만드는 특수 목적 skill이다.
setup-pre-commit	pre-commit hook 설정	Husky, lint-staged, Prettier, 타입 검사, 테스트로 커밋 전 검증 루프를 만든다.

개발 중인 스킬

저장소에는 skills/in-progress/에 개발 중인 skill도 있다. README와 플러그인 목록에서 빠져 있고, 완성도가 낮거나 동작이 바뀔 수 있다고 명시돼 있어 핵심 분석에서는 제외하고 후보로만 둔다.

Skill	역할	비고
review	변경 사항 리뷰	코딩 표준 준수와 원래 issue·PRD 충실도라는 두 축으로 diff를 검토한다.
teach	학습 작업공간 운영	MISSION.md, GLOSSARY.md, RESOURCES.md, 학습 기록으로 장기 학습 세션을 관리한다.
writing-beats	글을 장면 단위로 작성	독자가 다음 장면을 고르는 방식으로 글을 한 단계씩 전개한다.
writing-fragments	글감 조각 수집	앞으로 쓸 글의 원재료가 될 조각을 질문으로 끌어낸다.
writing-shape	원재료를 글 구조로 정리	마크다운 원재료를 문단 단위로 다듬는다.

Relevance

Pocock의 저장소는 문서·이슈·테스트를 skill과 함께 운영하는 사례로, 하네스 엔지니어링은 모델 바깥의 실행 환경을 설계하는 일이다를 설명할 때 구체 예로 쓸 수 있다. 에이전트 작업 흐름을 프롬프트, 컨텍스트, 도구 가운데 하나로만 설명하기 어렵다는 점이 드러난다. skill 자체는 프롬프트이지만, 저장소가 강조하는 것은 문서·이슈·테스트·코드 구조를 묶는 운영 루프다.

Open Questions

• GitHub·Linear 없이 순수 로컬 파일로 운영해도 같은 품질이 나오는가? issue tracker가 없는 개인 프로젝트라면 to-prd, to-issues의 산출물을 무엇으로 대체해야 하는가?
• 개인 개발자와 팀 개발에서 필요한 skill 단위의 크기가 같은지 불명확하다.
• skill이 많아질수록 트리거 충돌과 운영 비용이 생길 수 있다.
• skill을 프롬프트 엔지니어링의 하위 범주로 볼 것인가, 하네스 구성요소로 볼 것인가?
• CONTEXT.md와 ADR을 강하게 요구하는 작업 흐름이 작은 저장소에도 비용 대비 효과적인가?

Connections

• 하네스 엔지니어링은 모델 바깥의 실행 환경을 설계하는 일이다 — 이 저장소가 구체 사례가 되는 하네스 정의 노트
• Architecture Decision Record (ADR) — grill-with-docs가 작업 중 갱신하는 결정 기록
• Agent Skills - AI 에이전트에게 전문성을 부여하는 방법 — SKILL.md 형식과 skill 개념 자체

Related MOCs

• [[MOCs - Harness Engineering]]