한국어 제목

Matt의 AI 엔지니어링 스킬을 직접 써봤다

URL: https://www.youtube.com/watch?v=0oXOOlqVu5M
날짜: 2026-08-19
채널: t3dotgg

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==다른 사람이 공개한 에이전트 스킬을 통째로 복사할 것인가, 아니면 자신의 작업 기록과 습관에 맞는 부분만 검증하고 편집해 개인 도구 상자로 만들 것인가?==

• Matt Pocock의 skillsengineering은 작은 Markdown 파일만으로 AI 코딩 에이전트의 사고 과정과 작업 흐름을 바꾼다.
• Lauren(Potato)의 Pstack은 unslop, blast radius, arena, show me your work처럼 읽기 품질·검증·병렬 작업을 개선하는 실용적인 스킬을 제공한다.
• 가장 큰 효과는 스킬을 많이 설치하는 데서 나오지 않고, 자신의 저장소와 과거 에이전트 사용 기록을 감사한 뒤 필요한 트리거와 워크플로만 골라 수정하는 데서 나온다.

공개 스킬은 정답이 아니라 참고 자료다. 코드베이스 템플릿을 그대로 가져다 쓰면 엔지니어링을 배우지 못하듯이, 남의 에이전트 설정을 그대로 복사하면 자신의 문제와 작업 방식에 맞지 않는 처방을 떠안게 된다. 실제 가치가 확인된 한두 개의 작은 Markdown 파일부터 시험하고, 결과를 읽고, 필요한 부분만 fleet 같은 개인 저장소에 모아 관리하는 접근이 가장 현실적이다.

---

1. 두 스킬 컬렉션을 직접 감사하게 된 배경

1.1. Matt Pocock과 20만 개가 넘는 GitHub 별

1. 오래 지켜본 저장소

   1. t3dotgg는 오랫동안 관심만 두고 실제로 깊게 파고들지 못했던 GitHub 저장소를 소개한다.
   2. 저장소 주인은 과거 여러 차례 교류했던 Matt Pocock이며, TypeScript 분야에서 자신을 “두 번째로 좋은 YouTuber”라고 부르게 만든 첫 번째 인물이기도 하다.
   3. Matt는 실제 엔지니어를 위한 AI 스킬 묶음을 공개했고, 작은 Markdown 파일들이 20만 개가 넘는 GitHub 별을 받았다.
   4. 이 저장소는 GitHub 전체에서 별이 가장 많은 프로젝트 10개 안에 들어갈 정도로 성장했다. 실행 파일이나 거대한 프레임워크가 아니라 Markdown 파일만으로 얻은 수치라는 점이 핵심적인 화제다.

2. 초기 회의와 재평가

   1. 처음에는 Matt의 스킬을 대수롭지 않게 여겼지만, Matt가 계속 현실적인 방향으로 다듬는 모습을 보며 평가가 바뀌었다.
   2. 특히 grill me 스킬을 좋게 평가하는 사람들이 많았고, 실제로 사용한 사람들의 반응이 관심을 더 키웠다.
   3. Twitch 채팅에서도 이 주제를 오래 기다렸다는 반응이 쏟아졌다. 시청자들은 “새벽 3시까지 기다렸다”, “오래 미뤄진 약속이 드디어 나왔다”는 식으로 농담했다.
   4. Matt가 Notion에 처음 공개한 뒤 여러 차례 스킬을 업데이트했기 때문에, 예전 글만 읽는 것보다 현재 저장소를 직접 감사하는 일이 필요했다.

1.2. Lauren(Potato)의 Pstack을 함께 살핀 이유

1. 또 하나의 실전 컬렉션

   1. Matt의 스킬만 검토하면 AI 에이전트 스킬 생태계 전체를 제대로 판단하기 어렵다.
   2. Lauren, 즉 Potato는 과거 React 코어 팀에서 활동했고 현재 Cursor에서 일하며, React 컴파일러의 핵심 기여자 중 한 명으로 소개된다.
   3. Lauren이 만든 Pstack은 재미있으면서도 놀라울 만큼 강력한 스킬 묶음이다.
   4. 두 컬렉션의 대부분을 직접 읽고 감사한 뒤, 자신에게 맞는 항목을 가져와 며칠간 실제 작업에 사용했다.

2. 첫 관심사는 문체 품질이었다

   1. Pstack의 unslop 스킬을 먼저 주목한 계기는 Lauren이 공개한 에이전트 결과물이 평소 Claude가 쓰는 글보다 덜 어색하고 덜 “AI 같다”는 인상을 줬기 때문이다.
   2. 어떤 스킬이 유행한다는 이유만으로 결론을 내리지 않고, 실제로 설치하고 써 본 뒤 판단하기로 했다.
   3. 이 과정을 통해 스킬의 설계 방식, 트리거, 모델 호출 여부, 다른 스킬과의 결합 구조까지 함께 살피게 됐다.

---

2. 후원 구간에서 드러난 병렬 개발의 문제

2.1. 한 번에 여러 일을 하는 개발 환경

1. 병렬성이 만든 운영 문제

   1. 한 가지 일만 하던 시대는 지났고, 여러 에이전트와 프로젝트를 동시에 돌리는 일이 자연스러워졌다.
   2. 그 결과 코드를 어느 환경에서 실행해야 하는지, CI가 실제로 효율적으로 병렬 실행되는지, 회사 전체에서 어떤 프로젝트가 배포되고 있는지 파악하는 일이 어려워졌다.
   3. 이런 상태를 손으로 관리하면 반복적인 운영 부담이 커진다.

2. Depot이 제시한 해결책

   1. Depot은 GitHub CI와 Docker 빌드를 빠르게 만드는 서비스로 소개된다.
   2. 실제 사용 사례에서 최대 55배 빠른 빌드를 제공하고, 팀 전체와 CI가 Docker 빌드 캐시를 공유해 초기 작업 속도를 높인다고 설명한다.
   3. GitHub Actions도 전통적인 GitHub Actions CI보다 최대 10배 빨라질 수 있으며, Depot CI 러너를 추가하면 실제 병렬성까지 확보할 수 있다.
   4. depot cloud를 사용하면 자신의 클라우드 코드로 실제 이미지와 프로젝트를 클라우드 원격 샌드박스에 띄울 수 있다.
   5. 자세한 안내 링크로 soyv.link/depo가 제시됐다.

2.2. 빌드 병렬성과 작업 병렬성의 차이

1. 빌드만 빨라도 충분하지 않다
   1. CI와 Docker 빌드를 병렬화하는 일은 중요하지만, 여러 코딩 에이전트를 동시에 운영하는 작업 병렬성과는 다른 문제다.
   2. 원격 에이전트 샌드박스는 실제 프로젝트와 실제 이미지를 클라우드에서 실행해 개발자가 작업 환경을 직접 준비하는 부담을 줄인다.
   3. 이 문제의식은 뒤에서 다루는 arena, show me your work, fleet 저장소 같은 스킬 운영 방식과도 연결된다.

---

3. 남의 설정을 복사하지 말아야 하는 이유와 개인 감사 방식

3.1. 복붙은 코드 템플릿을 사는 것과 같다

1. 스킬을 명령 목록으로 취급하지 않기

   1. 공개 스킬은 따라야 할 단계 목록이 아니라, 자신의 AI 코딩 시스템을 만들 때 고려할 정보 모음으로 다뤄야 한다.
   2. 다른 사람의 코드베이스를 그대로 복사하고 이름만 바꾸면 좋은 엔지니어가 될 수 없듯이, 다른 사람의 스킬 설정을 그대로 설치해도 좋은 에이전트 운영자가 되지 못한다.
   3. 남의 정확한 설정을 맹목적으로 복사하는 일은 비싼 코드 템플릿을 구매하는 것과 같고, 자신의 문제를 이해하지 못한 채 남의 취향을 떠안는 결과를 낳는다.

2. 작은 시작점

   1. 수백 개의 스킬을 한꺼번에 설치하지 말고, 관심이 가는 Markdown 파일 하나를 복사해 현재 에이전트에서 시험하는 편이 낫다.
   2. 스크립트나 외부 자원이 필요한 스킬은 해당 스크립트를 함께 옮기거나, 에이전트에게 필요한 자원을 찾아 설정하도록 지시할 수 있다.
   3. 텍스트로 된 스킬은 설치하지 않고도 내용을 복사해 동작을 확인할 수 있다.

3.2. Pstack을 자신의 작업 기록에 대조한 프롬프트

1. 감사 대상과 절차

   1. MacBook, Leftbook, BB1 등 주로 사용하는 컴퓨터 세 대의 사용 기록을 조사하도록 에이전트에 요청했다.
   2. 프롬프트는 “내 작업과 Pstack 스킬 중 어떤 항목이 잘 맞는지 찾아 달라”는 요청으로 시작했다.
   3. 먼저 과거 기록을 불러온 뒤 하위 에이전트를 나눠 감사하고, 각 스킬의 적합도와 업무에 줄 수 있는 이익을 순위화하도록 했다.
   4. 당시 남아 있던 Opus 5 사용량을 활용했기 때문에 모든 감사 작업에 Opus 5를 지정했다.

2. 감사 결과

   1. 에이전트는 Pstack의 모든 스킬을 목록화하고, 적합도·예상 이익·간단한 이유를 문서로 정리했다.
   2. interrogate, blast radius, technical writing arena, prove it work 등이 특히 높은 순위에 올랐다.
   3. 이후 같은 방식으로 Matt Pocock의 스킬 저장소도 연결해 자신의 사용 사례에 맞는 항목을 비교했다.
   4. 이 감사 문서는 “무엇이 유명한가”가 아니라 “내가 실제로 하는 작업과 무엇이 맞는가”를 기준으로 선택하게 해 준다.

---

4. Pstack의 unslop: 에이전트 글을 읽을 수 있게 만드는 작은 규칙

4.1. 스킬의 설명은 백과사전이 아니라 트리거다

1. 모델이 보는 정보

   1. 에이전트는 모든 스킬의 이름과 설명을 볼 수 있고, 현재 작업에 유용해 보이는 스킬을 설명만 보고 불러온다.
   2. 실제 스킬을 호출하면 Markdown 파일 전체가 모델의 컨텍스트에 들어온다.
   3. 따라서 설명은 스킬이 할 수 있는 모든 일을 정확히 요약하는 문서가 아니라, 적절한 상황에서 모델이 그 스킬을 선택하도록 만드는 트리거여야 한다.

2. 썸네일과 트리거의 비유

   1. YouTube 썸네일은 영상의 모든 내용을 정확히 담는 것이 아니라, 올바른 사람이 멈춰서 클릭하게 만드는 역할을 한다.
   2. 스킬 설명도 같은 방식으로 필요한 에이전트가 “지금 이 스킬이 유용하겠다”고 판단하게 해야 한다.
   3. 오래된 Anthropic 규격이 이를 description이라고 부르지만, 실제 역할은 trigger에 가깝다는 관찰이 나온다.

4.2. unslop이 요구하는 글쓰기 변화

1. 기본 처리 순서

   1. AI가 자주 만드는 문체 패턴을 훑는다.
   2. 의미를 보존하면서 문장을 다시 쓰고, 의도한 어조를 맞춘다.
   3. 글에 개성과 “영혼”을 더한 뒤, “무엇이 이 글을 명백히 AI가 쓴 것처럼 보이게 하는가?”라고 자체 감사한다.
   4. 남은 흔적을 다시 고친다.

2. 사람다운 문체의 조건

   1. 패턴을 지우는 일만으로는 부족하다. 무미건조하고 목소리 없는 글도 쉽게 AI 글처럼 보인다.
   2. 사실을 중립적으로 장단점만 나열하지 말고, 사실에 반응하는 의견을 넣어야 한다.
   3. 짧은 문장과 오래 호흡하는 긴 문장을 섞어 리듬을 만든다.
   4. 복잡성을 인정하고, “인상적이지만 어딘가 불안하다”처럼 서로 다른 감정을 함께 표현한다.
   5. 적절할 때 1인칭을 쓰고, 지나치게 완벽한 구조에 약간의 자연스러운 흐트러짐을 허용한다.
   6. “우려스럽다”처럼 추상적인 말을 쓰기보다 “에이전트가 새벽 3시에 계속 작업하는 모습이 불안하다”처럼 구체적으로 쓴다.

3. 고쳐야 할 패턴

   1. pivotal moment, testament to, evolving landscape, setting the stage 같은 과장된 콘텐츠 수사를 잘라내고 실제로 일어난 일을 말한다.
   2. 맥락 없이 언론사나 유명 매체 이름을 나열하지 말고, 실제로 무엇이 보도됐는지 한 가지를 골라 쓴다.
   3. highlighting, ensuring, reflecting, showcasing 같은 피상적인 동명사형 연결어를 삭제한다.
   4. 홍보 문구, 막연한 긍정 표현, 챗봇이 습관적으로 쓰는 I hope this helps, Let me know if... 같은 마무리를 걷어낸다.
   5. Opus 계열에서 여전히 자주 나타나는 em dash(긴 대시) 과용도 점검한다. Matt의 스킬 자체에서 긴 대시가 반복되는 점은 역설적인 약점으로 지적된다.
   6. load-bearing 같은 유행어와 과도한 전문 용어를 불필요하게 쓰지 않는다.

4. 가장 강력한 규칙: 느낌이 아니라 기능을 쓰기

   1. “데이터베이스가 가까이 있다”처럼 시스템이 주는 느낌을 쓰지 말고, “SQL이 데이터베이스에 보낸 정확한 문자열을 반환한다”처럼 실제 동작을 쓴다.
   2. 각 문장이 독자에게 무엇을 알리거나 무엇을 하게 하는지 묻는다.
   3. 간결한 지시·사실·숫자로 다시 쓸 수 없다면 문장을 삭제한다.
   4. 그 문장을 다른 프로젝트 문서에 그대로 붙여도 자연스럽다면, 현재 프로젝트에 대해 아무것도 말하지 않는 것이므로 잘라낸다.

4.3. 같은 모델에서도 읽기 경험이 달라진 결과

1. T3 Code 설명 실험

   1. unslop을 적용한 에이전트에 T3 Code가 무엇이고 왜 관심을 가질 만한지 물었다.
   2. 결과는 “T3 Code는 코딩 모델도 아니고 주로 쓰는 편집기도 아니다”라고 선을 긋고, 명령 실행·프로젝트 열기·스레드 시작·프로젝트 검사 및 변경·메시지와 코드 변경 검토·데스크톱 브라우저나 휴대폰에서 이어 하기라는 흐름을 짧게 설명했다.
   3. T3 Code는 터미널, 에이전트 세션, Git diff, 체크포인트를 관리하며, 각 턴의 체크포인트로 에이전트 변경 사항을 검사하거나 되돌릴 수 있다는 내용도 포함했다.
   4. 여러 제공자의 에이전트를 별도 터미널 프로그램이 아니라 데스크톱·웹·iOS·Android에서 쓰는 하나의 작업공간으로 바꾼다는 핵심 가치가 드러났다.

2. 적합한 사용 사례

   1. 여러 제공자를 한 인터페이스에서 사용한다.
   2. 스레드가 지속되므로 작업을 쉽게 재개한다.
   3. 다른 컴퓨터에서 실행 중인 에이전트를 휴대폰이나 브라우저로 제어한다.
   4. 서버가 실행되는 동안 파일과 제공자 인증 정보는 해당 컴퓨터에 남는다.
   5. 여러 자율 개발자를 여러 터미널 탭에 흩어놓지 않고 운영하는 것이 가장 강한 설득 포인트다.

3. 스킬이 없는 결과와의 대비

   1. 같은 대략적인 질문을 일반 ChatGPT에 던지면 핵심 아이디어는 전달되지만, 문장이 더 장황하고 홍보성 표현과 추상적인 설명이 늘어난다.
   2. 같은 모델에 Markdown 파일 하나만 추가했는데도 두 결과의 가독성이 크게 달라졌다.
   3. 적용 전 글을 다시 읽을 때 불편함이 즉시 느껴질 정도로, unslop은 에이전트 답변을 읽고 싶은 마음 자체를 바꿨다.

---

5. Matt Pocock의 skillsengineering 구조와 핵심 흐름

5.1. 주요 디렉터리와 호출 방식

1. 관심 대상

   1. 핵심 디렉터리는 skillsengineering이다.
   2. 주요 스킬로 ask Matt, code review, codebase design, diagnosing bugs, domain modeling, grill with docs, implement, improve codebase architecture, prototype, research, resolving merge conflicts, set up Matt Pocock skills, TDD, dissect, tickets, triage, wayfinder, wizard 등이 소개된다.
   3. teach, shaping, handoff, two questionnaire, wait what, writing for agents와 같은 생산성·설계 보조 스킬도 함께 언급된다.

2. 사용자 호출과 모델 호출의 분리

   1. 많은 스킬에는 모델 자동 호출을 막는 disable model invocation 설정이 있다.
   2. 이런 스킬은 /skill 또는 $skill 같은 명시적인 명령으로 불러야 하므로, 계획이 명확한 순간에만 강한 워크플로가 개입한다.
   3. 반대로 diagnosing bugs처럼 문제 상황을 감지했을 때 자동으로 등장해야 하는 스킬은 모델 호출을 막지 않는다.
   4. 사용자 호출형 플러그인과 모델의 작업 방식을 지속적으로 조정하는 모델 호출형 스킬을 구분하면, 에이전트가 원하지 않는 순간에 긴 인터뷰를 시작하는 일을 줄일 수 있다.

5.2. grill with docs: 설계를 질문으로 압축하는 흐름

1. 스킬의 목적

   1. grill with docs는 계획과 설계를 끈질기게 인터뷰하면서 더 날카롭게 만들고, 그 과정에서 문서·ADR·용어집을 작성한다.
   2. 내부적으로 다른 스킬을 호출할 수 있지만, 실제 텍스트는 놀라울 만큼 짧고 단순하다.
   3. grilling 스킬은 계획·결정·아이디어를 상대로 질문을 이어가며, 의사결정 트리를 그린다.
   4. 각 결정의 선행 조건이 해결된 항목을 현재 frontier로 삼고, 라운드마다 결정 트리의 다음 갈래를 확정한다.

2. Lakebed 프로젝트에 적용한 첫 질문

   1. Lakebed의 프로젝트 목표와 AGENTS.md, CLAUDE.md 같은 지침을 모두 읽은 뒤 자신을 상대로 질문하도록 했다.
   2. 실제 첫 질문은 “현재 CLAUDE.md가 오래됐고, 저장소 안에 서로 경쟁하는 실행 모델이 두 개 있다”는 사실을 짚었다.
   3. 누가 사용자이고 누가 비용을 지불하는지, 당장의 다음 마일스톤이 무엇인지, 출시 준비 파일과 무작위 계획 문서가 섞인 상태에서 무엇을 기준으로 삼을지 질문했다.
   4. 캡슐 형식이 사양인지 구현 세부인지, 캡슐 하나가 가질 수 있는 최대 규모가 얼마인지도 물었다.

3. 설계 질문을 대화형 선택지로 바꾼 결과

   1. 주요 사용자는 누구인지, 완전한 자율성이 무엇을 뜻하는지, 캡슐이 무엇인지가 핵심 질문으로 정리됐다.
   2. 에이전트가 결제 세부 사항 외에는 모든 일을 하게 할지, Lakebed가 무엇을 소유해야 하는지, 단순성 원칙과 필요할 때의 재작성 중 무엇을 우선할지 선택했다.
   3. 로컬은 개발용 시뮬레이션으로만 두고 호스팅 클라우드 플랫폼을 운영 경로로 삼을지, 앱 기능 외의 아키텍처·데이터 모델·배포 시점을 개발자가 결정하지 않도록 할지 답했다.
   4. 질문을 한 번에 하나씩 길게 쓰는 대신 1A, 2B처럼 빠르게 선택할 수 있는 형식이 제시됐다. 에이전트의 질문 UI가 불편할 때도 이 방식이 더 빠르다는 평가다.
   5. Opus 5는 원격 Linux 박스에서 거의 2분 동안 저장소를 조사한 뒤 첫 질문을 내놓았고, 다른 모델은 저장소 사실을 충분히 찾지 않고 질문했다. 높은 추론 설정은 배경 하위 에이전트를 띄워 더 많은 근거를 수집했다.

4. 직접 답하면서 발견한 설계 문제

   1. 단순성에는 구현·사용자 경험·운영 등 서로 다른 종류가 있는데, 어느 종류를 가장 우선할지 강제로 골라야 했다.
   2. Lakebed가 지원해야 할 앱, 개발자와 에이전트의 권한 분배, 아키텍처·데이터 모델·배포 시점의 소유권을 구체화했다.
   3. 되돌릴 수 없는 작업까지 자율 에이전트에 허용할지, 프로덕션 데이터를 삭제할 수 있게 할지, 구독과 월간 한도 안에서 결제를 어디까지 허용할지 결정했다.
   4. 로컬 시뮬레이션이 보존해야 할 특성도 정의했다. 권장 답변에 자주 동의하지 않았지만, 바로 그 불일치가 숨은 결정을 표면으로 끌어냈다.

5.3. Matt 스킬을 안전하게 시험하는 복사·붙여넣기 방법

1. 설치 전 행동 확인

   1. 관심 있는 스킬의 Markdown 내용을 그대로 복사해 에이전트 프롬프트에 붙여 넣으면, 별도 설치 없이 텍스트 스킬의 동작을 시험할 수 있다.
   2. 이 방법은 스킬이 무엇을 요구하는지, 질문을 어떤 순서로 만드는지, 결과가 자신의 작업 방식과 맞는지 빠르게 확인하게 한다.
   3. 스크립트가 연결된 스킬은 같은 방법만으로 완전한 동작을 재현할 수 없지만, 스크립트를 함께 복사하거나 에이전트에게 찾아오게 할 수 있다.

2. 자동 호출이 적절한 경우

   1. 버그 진단처럼 실제 문제가 발생했을 때 자동으로 호출되는 스킬은 별도 명령 없이도 흐름에 자연스럽게 끼어든다.
   2. 계획을 장시간 인터뷰하는 grilling이나 여러 세션에 걸쳐 학습 상태를 저장하는 teach는 명시적으로 호출하는 편이 안전하다.
   3. 사용자가 정말 원하는 순간에만 강한 처방형 흐름을 켜야 일상적인 질문이 과도한 워크숍으로 변하지 않는다.

---

6. Matt 스킬을 실제 개발 도구 상자에 편입한 방식

6.1. teach, ask Matt, wizard와 설계 보조 도구

1. 상태를 저장하는 학습

   1. teach는 여러 세션에 걸쳐 배우려는 주제를 학습하는 상태 기반 요청을 처리한다.
   2. 현재 디렉터리를 교육 작업공간으로 삼고, 여러 파일에 학습 상태를 기록한다.
   3. 장기 학습 상태를 저장한다는 점에서 일반적인 일회성 질의와 구분된다.

2. 스킬 선택과 인간의 고유 작업

   1. ask Matt는 자신의 상황에 어떤 스킬이나 흐름이 맞는지 찾도록 돕는다.
   2. wizard는 에이전트가 접근할 수 없는 대시보드나 실행할 수 없는 의사 호출을 인간이 처리하도록 단계별로 안내한다.
   3. 필요한 설정을 사람이 완료하면 하나의 스크립트를 실행해 다음 단계로 이어갈 수 있다.
   4. 새로운 Mac Mini를 추가한 뒤 모든 컴퓨터에 wizard를 배포하도록 요청했고, 이전에 빠뜨린 설정을 에이전트가 확인해 설치했다.

6.2. fleet 저장소와 전체 작업 흐름

1. 모든 스킬을 한곳에서 관리하기

   1. 모든 설정은 이미 만든 fleet 저장소의 스킬 파일 관리 스레드에서 처리했다.
   2. fleet는 여러 컴퓨터의 스킬과 관련 파일을 한 계층에서 관리하므로, 새 장비가 추가돼도 같은 기준을 재적용할 수 있다.
   3. 이 저장소는 과거에도 설정을 복구하고 반복 작업을 재현하는 데 큰 도움이 됐다.

2. 기본 실행 순서

   1. grill with docs로 계획을 인터뷰하고 결정을 기록한다.
   2. spec으로 실행 가능한 사양으로 바꾼다.
   3. tickets로 Jira·Linear·GitHub Issues에 넣을 작업 단위로 자른다.
   4. implement로 실제 코드를 만든다.
   5. code review로 구현 결과를 검토한다.
   6. shaping은 모호한 아이디어를 실행 가능한 계획으로 바꾸고, wayfinder는 대규모 작업을 결정 지도 형태로 펼친다.
   7. prototype은 출시 전에 실제로 원하는 디자인과 상호작용을 확인하는 데 쓰며, 나중에 버려도 되는 코드를 만든다.

3. 참조·검증 스킬

   1. research는 1차 출처를 인용한 답을 얻는 흐름을 제공하지만, 평소 에이전트에게 주장을 검증하라고 요구하면 충분하다고 느껴 자주 쓸지는 확신하지 못했다.
   2. improve codebase architecture는 codebase design을 이용해 도메인 어휘와 후보 구조를 HTML 보고서로 만들고, 이어서 grilling과 domain modeling을 호출한다.
   3. domain modeling은 프로젝트에서 사용하는 단어와 문법을 용어집으로 정리한다.
   4. resolving merge conflicts, triage, diagnosing bugs, wizard는 실제 유지보수 상황에서 바로 쓸 수 있는 도구로 분류됐다.

6.3. 처방된 흐름을 그대로 따르지 않는 판단

1. 좋은 재료와 과한 처방

   1. Matt의 문서는 grill with docs → spec → tickets → implement → code review처럼 일관된 기본 흐름을 제시한다.
   2. 이런 흐름은 좋은 진입점이지만, 모든 개발자가 같은 단계와 순서를 원하지는 않는다.
   3. 자신은 이미 별도의 워크플로를 만들어 사용하고 있고, 전통적인 개발 절차와 완전히 겹치지 않는다.
   4. 따라서 흐름 전체를 설치하기보다 wizard, grilling, codebase design, 후속 정리 스킬 등 가치가 확인된 부분만 가져오기로 했다.

2. 실제 추가 질문

   1. “어떤 종류의 단순성이 중요한가?”라는 질문은 구현 단순성, 사용 단순성, 운영 단순성을 모두 원할 때도 하나를 선택하도록 강제했다.
   2. Lakebed가 지원할 앱, 개발자와 에이전트의 통제권, 되돌릴 수 없는 작업, 결제 경계, 로컬 시뮬레이션 보존 범위를 차례로 결정했다.
   3. 추천 답변과 자주 의견이 달랐지만, 불편한 선택을 강요하는 과정 자체가 설계의 빈틈을 드러냈다.
   4. 10개가 넘는 추가 질문은 스트림 밖에서 계속 답하기로 했고, 그 과정에서 T3 Code의 스킬 관리자 기능에 대한 새 아이디어도 생겼다.

---

7. 에이전트 문체·검증·병렬 작업을 개선한 Pstack 스킬

7.1. writing for agents: 다른 에이전트가 읽는 문서 쓰기

1. 필요성

   1. 에이전트는 다른 에이전트를 위한 스킬, AGENTS.md·CLAUDE.md, 하위 에이전트 프롬프트를 작성할 때 특히 서툴다.
   2. 에이전트에게 Markdown이나 지시문을 그냥 생성하게 두면, 모호하고 장황한 문서가 만들어져 다음 에이전트의 행동을 오염시킨다.
   3. writing for agents는 이런 문서를 작성할 때 적용할 기준을 제공한다.

2. 컨텍스트 포인터

   1. 스킬·에이전트 지침·포인터로 연결된 문서는 모두 에이전트가 나중에 읽을 외부 자료를 가리키는 컨텍스트 포인터로 볼 수 있다.
   2. 포인터의 문구와 대상 문서 중 무엇이 더 중요한지 판단해야 하며, 어떤 조건에서 자료를 읽어야 하는지가 명확해야 한다.
   3. 반드시 읽어야 할 문서를 약한 표현으로 가리키면, 에이전트가 자료를 건너뛰는 분산 버그가 생긴다.
   4. 스킬 문서를 만들 때는 front matter, 호출 방식, 라우터 스킬 규칙을 다루는 skill mechanics 문서도 읽어야 한다.

3. 문체에 대한 역설

   1. Pstack의 글은 AI 생성 문서 감지 도구에서 100% 인간 작성으로 분류됐고, Matt의 글은 AI 생성으로 분류되는 실험 결과가 나왔다.
   2. 그러나 자동 감지 결과는 신뢰하기 어렵다. 두 컬렉션 모두 AI가 초안을 썼을 가능성이 있고, unslop 스킬도 AI 생성으로 판정됐기 때문이다.
   3. 판정 결과와 무관하게 Pstack의 글과 스킬 행동이 일상 업무에 더 읽기 쉽고 적용하기 좋았다는 평가가 남는다.
   4. Markdown이 AI처럼 보이는 것이 아니라, 문장 밀도·구체성·행동 지침이 품질을 가르는 더 중요한 기준이다.

7.2. arena: 같은 작업을 여러 번 실행하고 합성하기

1. 단계별 병렬 처리

   1. arena는 같은 작업을 여러 번 병렬로 실행한다.
   2. 모든 후보를 처음부터 끝까지 읽은 뒤 가장 강한 결과를 기반으로 삼는다.
   3. 다른 후보의 좋은 아이디어를 기반 결과에 그래프로 연결하듯 이식하고, 합성 결과를 검증한다.
   4. 기본 단계는 frame → fan out → cross judge → pick → graft → verify로 정리된다.

2. 비용과 기록

   1. 시작 전에 단계마다 하나씩 항목을 가진 할 일 목록을 만들면, 자율 실행 중 단계가 조용히 사라지는 일을 막을 수 있다.
   2. 단순한 텍스트로 큰 효과를 내지만 같은 작업을 여러 번 수행하므로 추론 비용이 수백 달러까지 늘어날 수 있다.
   3. 토큰 사용량이 넉넉하고 품질을 위해 병렬 후보를 비교할 때 특히 잘 맞는다.
   4. Pstack의 설명과 구현이 Cursor에 밀착된 점은 범용 사용의 가장 큰 약점이다. 일반적인 에이전트 환경에 맞게 포팅하면 활용 가치가 더 커진다.

7.3. bro, blast radius, show me your work

1. bro와 wait what

   1. Dylan Moy가 처음 만든 것으로 추정되는 bro는 마지막 답변을 다시 쓰게 하며, 전문 용어를 줄이고 사람 사이의 대화처럼 더 단순하고 간결하게 만든다.
   2. 기능적으로 Matt의 wait what과 거의 같고, Pstack 쪽에서는 bro가 명시적 호출형으로 설정된 점이 특징이다.
   3. 복잡한 답변을 받은 뒤 즉시 짧고 명료한 문장으로 바꾸는 용도다.

2. blast radius

   1. blast radius of X 또는 what could this break?라고 요청하면 변경 사항이 다른 곳에서 무엇을 망가뜨릴 수 있는지 조사한다.
   2. how가 코드가 무엇을 하는지, why가 왜 그런 구조인지 설명한다면, blast radius는 그 코드가 다른 부분에 어떤 파급을 일으키는지 찾는다.
   3. 스스로 작성한 설명을 신뢰하지 말고, 전체 결론이 의존하는 한두 가지 사실을 실제 코드를 실행해 증명하라고 요구한다.
   4. 이 스킬은 몇 차례 큰 고생을 미리 막아 줬고, 답변을 다시 unslop으로 통과시켜 읽기 좋은 형태로 만드는 흐름까지 포함한다.

3. show me your work

   1. 장시간 실행되거나 사람이 자리를 비운 동안 진행되는 작업에는 검토 가능한 의사결정 기록이 필요하다.
   2. 이 스킬은 결정마다 what, why, evidence, result를 한 행에 적는 로컬 TSV 로그를 만든다.
   3. 한 행에 담기지 않을 만큼 복잡한 결정은 아직 충분히 명확하지 않다는 신호로 본다.
   4. 기록은 추가만 가능한 append-only 방식으로 유지하고, 틀린 판단은 이전 행을 덮어쓰지 않고 새 행으로 대체한다.
   5. 손으로 만든 일회성 결과보다 커밋된 스크립트가 만든 증거를 연결하면 검토자가 다시 실행할 수 있다.
   6. 자율·다단계 작업, 사람이 나중에 검토할 작업, 자리를 비운 뒤 신뢰해야 하는 작업에 적합하다.

---

8. 실제 사용 경험에서 얻은 평가와 개인 도구 상자 전략

8.1. 철학적으로 더 가까웠던 부분

1. Pstack에 대한 선호

   1. 두 컬렉션을 경쟁 구도로 만들려는 의도는 없었지만, 실제 사용 뒤에는 Potato가 만드는 방향에 철학적으로 더 가까움을 느꼈다.
   2. Pstack은 짧은 텍스트로 구체적인 행동을 유도하고, 읽기 품질과 검증을 작업 흐름 안에 넣는다.
   3. Matt의 컬렉션은 더 체계적인 정신적 워크플로와 전통적인 개발 단계를 처방하는 경향이 강하다.
   4. 두 접근 모두 좋은 재료를 제공하지만, 자신의 비전통적인 작업 순서에는 Pstack의 유연성이 더 잘 맞았다.

2. unslop의 즉각적인 효과

   1. 에이전트의 말을 읽는 일이 싫어지는 문제를 단순한 모델 교체가 아니라 Markdown 지침 하나로 크게 줄였다.
   2. 같은 코드베이스와 같은 에이전트·모델을 사용해도 문장 구조와 정보 밀도가 달라졌다.
   3. 이 변화 덕분에 에이전트 결과를 더 자주 읽고, 검토하고, 병렬 작업을 계속 맡길 수 있었다.

8.2. T3 Code에 생긴 스킬 관리자 아이디어

1. 크로스 컴퓨터 관리

   1. 이미 개발 중이던 T3 Code의 스킬 관리자 기능을 여러 컴퓨터의 스킬을 한 계층에서 관리하는 화면으로 확장하고 싶어졌다.
   2. Pstack 그룹과 Matt Pocock 그룹처럼 스킬을 묶고, 그룹 전체를 켜고 끄거나 필요한 항목만 켤 수 있어야 한다.
   3. 새 Mac Mini를 포함해 모든 머신에 동일한 설정을 배포하고, 특정 프로젝트에는 일부 스킬만 활성화하는 방식이 필요하다.

2. 설치보다 운영

   1. wizard를 모든 머신에 설치했지만 당장 쓸 상황은 없었다.
   2. 그럼에도 사람이 해야 하는 대시보드 조작과 에이전트가 수행할 수 있는 코드 작업을 분리해 준다는 점에서 기대가 컸다.
   3. 스킬의 가치는 설치 개수보다 언제 켜지고, 어떤 저장소에 적용되며, 어떻게 업데이트되는지 관리하는 능력에서 나온다.

8.3. 병렬 에이전트 작업에 미친 영향

1. 작업 방식의 변화

   1. Markdown 파일과 환경 변수를 직접 편집하는 일이 코드 편집기에서 가장 빈번한 작업이 됐다.
   2. 여러 에이전트를 병렬로 운영할 수 있는 기반이 마련됐고, 지난 주말에는 적은 파손으로 많은 PR을 배포할 수 있었다.
   3. blast radius, show me your work, arena, unslop이 각각 파급 범위, 근거 기록, 후보 비교, 읽기 품질을 맡으면서 병렬 작업의 신뢰성이 높아졌다.

2. 보수적인 선택

   1. 기존 설정이 만족스럽다면 전체 컬렉션을 설치해 작업을 흐리지 않아야 한다.
   2. 자신이 자주 겪는 문제를 하나 골라 해당 스킬만 가져오고, 실제 결과를 검토한 뒤 다음 항목을 선택한다.
   3. 공개 파일을 직접 열어 편집하는 일을 두려워하지 않아야 한다. 스킬은 완성품이 아니라 자신의 환경에 맞춰 조정할 수 있는 Markdown 코드다.

---

주요 발언 모음

“다른 사람의 설정을 맹목적으로 복사해서는 아무것도 얻지 못한다. 자신의 AI 코딩 시스템을 만들 때 참고할 정보로 다뤄야 한다.”

“설명(description)이라고 부르지만, 실제 역할은 트리거(trigger)다. 올바른 에이전트가 올바른 작업에 그 스킬을 가져오게 해야 한다.”

“느낌이 어떤지 말하지 말고 무엇을 하는지 말하라. 문장이 독자에게 무엇을 알리거나 무엇을 하게 하는지 묻고, 간결한 사실·지시·숫자로 쓸 수 없다면 잘라내라.”

“unslop을 설치한 뒤부터 에이전트가 말하는 내용을 읽고 싶은 마음이 훨씬 커졌다.”

“grill with docs에서 spec, tickets, implement, code review로 이어지는 흐름은 좋은 재료지만, 남의 단계 전체를 그대로 따라야 한다는 뜻은 아니다.”

“스킬을 500개 설치하지 말고, 공개된 파일을 읽고, 시험하고, 필요한 부분만 가져와라.”

“자신의 파일을 직접 열어 편집하는 일을 두려워하지 마라. 지금은 코드 편집기를 여는 이유가 Markdown과 환경 변수를 고치는 일인 경우가 많다.”

---

핵심 데이터 & 수치

• 20만 개 이상: Matt Pocock의 AI 스킬 GitHub 저장소가 받은 별의 규모다.
• GitHub 상위 10위권: 실행 코드가 아니라 작은 Markdown 파일로 구성된 저장소의 별 순위다.
• 3대 머신: Pstack 적합도 감사를 위해 MacBook, Leftbook, BB1의 사용 기록을 비교했다.
• Opus 5: 초기 적합도 감사와 Lakebed 질문 실험에 사용한 모델이다.
• 약 2분: 원격 Linux 박스에서 Opus 5가 저장소 사실을 조사한 뒤 첫 grilling 질문을 내놓기까지 걸린 시간이다.
• 최대 55배: 후원 구간에서 Depot의 실제 사용 사례 기준 빌드 속도 향상 수치로 제시됐다.
• 최대 10배: Depot을 사용한 GitHub Actions 속도 향상 수치로 제시됐다.
• 수백 달러: arena가 같은 작업을 여러 후보로 실행하고 비교하는 과정에서 소비할 수 있는 추론 비용이다.
• 10개 이상: Lakebed 설계와 운영 범위를 구체화하기 위해 추가로 답해야 했던 질문의 규모다.

---

결론 및 실행 포인트

1. 자신의 에이전트 사용 기록과 저장소를 먼저 감사하고, 공개 스킬을 업무 적합도와 예상 이익으로 순위화한다.
2. 처음에는 unslop처럼 작고 독립적인 Markdown 스킬 하나만 복사해 결과의 문체와 정보 밀도를 비교한다.
3. 스킬 설명을 정확한 기능 목록이 아니라 모델 호출을 유도하는 트리거로 설계한다.
4. 스킬을 자동 호출형과 사용자 명시 호출형으로 나눠 원치 않는 인터뷰나 강한 워크플로가 갑자기 시작되지 않게 한다.
5. grill with docs를 사용해 숨은 설계 결정을 질문으로 끌어내되, 제시된 단계 전체를 자신의 작업 방식에 강제로 맞추지 않는다.
6. 텍스트 스킬은 설치하기 전에 내용을 복사해 실제 에이전트에서 시험하고, 스크립트 의존성이 있는 부분은 별도로 확인한다.
7. blast radius로 변경이 다른 코드와 운영 경로에 미칠 파급 효과를 조사하고, 핵심 전제는 실제 코드를 실행해 검증한다.
8. 장기 자율 작업에는 show me your work의 TSV 형식처럼 결정·이유·근거·결과를 남기는 기록을 붙인다.
9. 여러 후보를 비교할 때는 arena를 활용하되, 반복 추론 비용이 수백 달러까지 커질 수 있음을 감안한다.
10. fleet 같은 개인 저장소에서 여러 머신의 스킬 파일을 버전 관리하고, 새 장비가 추가될 때 동일한 기준을 재적용한다.
11. writing for agents로 하위 에이전트 프롬프트와 Markdown 지침의 조건·호출 시점·근거 포인터를 구체화한다.
12. 공개 스킬의 좋은 부분만 가져오고, 자신의 프로젝트 어휘·권한 경계·배포 방식에 맞게 문구를 직접 편집한다.
13. Pstack의 Cursor 전용 가정을 그대로 옮기지 말고, 범용 에이전트 환경에 필요한 부분만 추출한다.
14. 스킬을 많이 갖는 것보다 어떤 문제를 해결하는지, 어느 프로젝트에서 켜는지, 업데이트를 어떻게 검증하는지가 중요하다.
15. 에이전트 결과가 읽기 어렵다면 모델을 바꾸기 전에 문체 규칙·구체성·문장 리듬을 교정하는 Markdown 지침을 시험한다.
16. 복잡한 답변을 받은 뒤 wait what이나 bro로 전문 용어를 걷어내고 한 사람이 다른 사람에게 말하듯 다시 쓴다.
17. 인간이 해야 하는 대시보드 조작과 에이전트가 할 수 있는 코드 작업은 wizard 같은 단계 안내 스킬로 분리한다.
18. 여러 에이전트를 병렬로 돌릴수록 실행 전 계획·검증·결정 기록이 필요하므로, 속도만 보고 안전 장치를 생략하지 않는다.
19. 다른 사람이 잘 쓰는 설정은 정답이 아니라 실험 재료이며, 자신의 역사와 사용 습관에 맞춘 작은 변경이 장기적으로 더 큰 효과를 낸다.
20. 공개 스킬을 읽고 시험하고 편집하는 과정을 반복하면 에이전트 작업량을 늘리면서도 결과의 파손과 읽기 부담을 줄일 수 있다.

---

핵심 요약 (20줄)

• Matt Pocock의 skillsengineering은 작은 Markdown 파일만으로 AI 코딩 에이전트의 사고와 작업 흐름을 바꾸는 공개 스킬 저장소다.
• 저장소는 20만 개가 넘는 GitHub 별을 받아 상위 10위권 프로젝트가 됐으며, 그 규모가 실행 코드가 아닌 Markdown에서 나왔다는 점이 인상적이다.
• Lauren(Potato)의 Pstack은 React 컴파일러 기여자이자 Cursor 개발자가 만든 또 다른 실전 스킬 컬렉션이다.
• 두 컬렉션을 통째로 설치하기보다 자신의 여러 컴퓨터 사용 기록과 대조해 적합도와 예상 이익을 순위화해야 한다.
• 스킬 설명은 모든 기능을 담은 문서가 아니라 올바른 상황에서 모델을 호출하는 트리거로 설계해야 한다.
• unslop은 과장된 수사, 챗봇식 마무리, 추상적인 전문 용어, 긴 대시 과용을 줄이고 구체적인 사람다운 문체를 유도한다.
• unslop은 사실을 중립적으로 나열하기보다 의견과 구체적인 사례를 넣고, 문장의 실제 기능을 직접 말하도록 요구한다.
• T3 Code 설명 실험은 같은 모델에 Markdown 지침 하나만 추가해도 답변의 가독성과 정보 밀도가 크게 달라질 수 있음을 보여줬다.
• T3 Code는 여러 코딩 에이전트 제공자를 하나의 데스크톱·웹·모바일 작업공간에서 운영하는 오픈 소스 제어 센터다.
• grill with docs는 계획과 설계를 끈질기게 질문하며 결정 사항과 문서·ADR·용어집을 함께 만든다.
• Lakebed 질문 실험은 사용자, 비용 지불자, 제품 경계, 캡슐 사양, 자율성, 결제와 파괴적 권한을 구체적으로 결정하게 했다.
• 질문을 선택지 형태로 빠르게 답하게 만들면 에이전트의 불편한 질문 UI보다 설계 인터뷰를 빠르게 진행할 수 있다.
• Matt의 스킬은 모델 자동 호출형과 사용자가 명시적으로 불러야 하는 호출형을 구분해 개입 강도를 조절한다.
• teach는 여러 세션의 학습 상태를 파일에 보존하고 wizard는 에이전트가 접근하지 못하는 인간 작업을 단계별로 안내한다.
• grill with docs → spec → tickets → implement → code review 흐름은 좋은 출발점이지만 개인 워크플로에 맞게 일부만 선택해야 한다.
• writing for agents는 다른 에이전트가 읽는 스킬·지침·하위 에이전트 프롬프트를 더 정확하게 작성하도록 돕는다.
• arena는 같은 작업의 여러 결과를 병렬 생성하고 교차 판단·합성·검증하지만 추론 비용이 수백 달러까지 커질 수 있다.
• blast radius는 변경이 다른 곳에서 일으킬 파손을 찾고, 핵심 사실을 실제 코드 실행으로 증명하도록 요구한다.
• show me your work는 결정·이유·근거·결과를 한 행에 기록하는 TSV 로그로 장시간 자율 작업의 신뢰성을 높인다.
• 가장 실용적인 전략은 fleet 같은 개인 저장소에서 필요한 스킬만 버전 관리하고 직접 편집하며, 자신의 작업 기록을 기준으로 계속 다듬는 것이다.