emilkowalski/skills는 인터페이스를 더 예쁘게 만드는 거대한 프롬프트 하나가 아니다. 커밋 7bb7061 기준으로 보면, 범용 디자인 스킬 하나와 범위가 더 좁은 전문 스킬 네 개, 그리고 비용이 큰 진단에서 자체 완결적인 실행 계획으로 이어지는 의도적인 핸드오프로 구성된 작은 판단 시스템이다.
이 분리가 곧 아키텍처다. 애니메이션 규칙도 중요하지만, 스킬 작성자가 더 널리 재사용할 수 있는 아이디어는 판단의 종류마다 어디서 시작하고, 무엇을 반환하며, 언제 멈춰야 하는지를 정한 방식에 있다.
다섯 파일, 서로 다른 다섯 계약
저장소는 emil-design-eng를 메인 스킬로 설명하고, 나머지 네 스킬에는 엄격한 애니메이션 리뷰, 코드베이스 전반의 점검과 계획, 어휘 조회, Apple에서 가져온 웹 디자인 지침이라는 더 좁은 역할을 맡긴다(README.md:42-48).
| 스킬 | 트리거 경계 | 출력 경계 | 시스템에서의 역할 |
|---|---|---|---|
animation-vocabulary |
사용자가 움직임을 설명할 수는 있지만 이름은 모를 때 | 가장 잘 맞는 용어와, 필요할 경우 한두 가지 대안 | 모호한 의도를 공통 언어로 정규화 |
emil-design-eng |
전반적인 UI 다듬기, 컴포넌트, 애니메이션 결정에 관한 질문 | 일반적인 디자인 엔지니어링 지침 | 재사용 가능한 감각의 중심 원칙을 담당 |
apple-design |
Apple 스타일의 제스처, 스프링, 모멘텀, 재질, 타이포그래피 또는 접근성 | Apple에서 가져온 원칙을 웹 기법으로 변환 | 직접 조작하는 듯한 물리적이고 중단 가능한 상호작용에 맞춰 범용 조언을 구체화 |
review-animations |
애니메이션 또는 모션 코드가 포함된 diff | 지적 사항, 영향도 등급, 명시적인 결정 | 원칙을 엄격한 로컬 게이트로 전환 |
improve-animations |
코드베이스 전반의 모션을 개선해 달라는 요청 | 검증된 점검 결과와 자체 완결적인 계획 | 진단과 명세에 판단력을 쓰고, 구현은 핸드오프 |
가장 작은 스킬에서 이 경계가 가장 선명하게 보인다. animation-vocabulary는 역방향 조회다. 모호한 설명을 받아 정확한 용어를 내놓는다. 효과의 이름을 붙이는 용도이지, 설계하거나 구현하는 용도가 아니라고 명시하며, 모호함을 다룰 때도 가장 잘 맞는 용어와 한두 가지 대안으로 제한한다(animation-vocabulary/SKILL.md:1-18). 이런 절제가 유용하다. 이 스킬은 이후의 모든 프롬프트를 개선하기 위해 구현 권한까지 가질 필요가 없다.
지식 계층은 범용 감각과 전문 감각으로 나뉜다
emil-design-eng는 범용 참고서다. 선언된 범위는 UI 다듬기, 컴포넌트 디자인, 애니메이션 결정, 소프트웨어의 완성도를 높이는 세부 요소까지 아우른다(emil-design-eng/SKILL.md:1-3). 이 스킬의 의사결정 프레임워크는 모션이 필요한지, 어떤 목적을 이루는지, 어떤 easing이 맞는지, 얼마나 오래 지속해야 하는지를 묻는다(emil-design-eng/SKILL.md:62-135).
apple-design은 같은 내용을 한 벌 더 복사한 스킬이 아니다. 유연하고 물리적인 상호작용으로 범위를 좁히고, WWDC에서 가져온 아이디어를 CSS, Pointer Events, requestAnimationFrame, 웹 스프링 라이브러리로 옮긴다고 명시한다(apple-design/SKILL.md:1-10). 구현 어휘도 더 구체적이다. pointer-down 반응, pointer capture, 연속 추적, 화면에 표시된 현재 값에서의 중단, 속도 블렌딩, 스프링 리타기팅을 다룬다(apple-design/SKILL.md:20-69).
따라서 지식 계층에는 두 가지 깊이가 있다. 메인 스킬은 “보통 무엇이 이 인터페이스의 느낌을 좋게 만드는가?”에 답한다. Apple 스킬은 “상호작용이 직접 조작하는 듯하고, 모멘텀을 인식하며, 중단 가능해야 할 때 그것은 무엇을 뜻하는가?”에 답한다.
리뷰는 또 하나의 조언 모드가 아니라 게이트다
review-animations는 범위를 날카롭게 줄인다. 애니메이션과 모션 코드만 리뷰한다. 기능을 작성하거나, 관련 없는 버그를 고치거나, 일반 코드를 리뷰하지 않는다. 지적 사항에 정확한 곡선, 지속 시간, 스프링 값 또는 인용이 필요하면 동반 문서인 STANDARDS.md를 참조한다(review-animations/SKILL.md:9-17).
이 스킬의 판단은 의도적으로 비대칭적이다. 타협할 수 없는 열 가지 기준을 위반하면 모두 지적 사항이 된다(review-animations/SKILL.md:19-41). 명시된 escalation trigger는 강하게 경고하며, 개선 순서는 더 나은 easing, 물리성, 중단 가능성, GPU 속성, 타이밍, 디테일, 접근성, 일관성으로 넘어가기 전에 모션을 삭제하거나 줄이는 데서 시작한다(review-animations/SKILL.md:43-74).
출력도 똑같이 제한된다. 첫 부분은 반드시 Before | After | Why 표 하나여야 한다. 두 번째 부분은 영향도별로 코멘트를 묶은 뒤 Block 또는 Approve로 끝낸다. 지적 사항에는 file:line을 사용하고, 정확한 값은 추정하지 않고 STANDARDS.md에서 가져온다(review-animations/SKILL.md:76-107).
여기서 감각은 실제로 작동하는 게이트가 된다. 일반적인 조언은 트레이드오프를 설명할 수 있다. 하지만 리뷰어는 다른 사람이나 에이전트가 행동으로 옮길 수 있는 안정적인 산출물을 내놓아야 한다.
improve-animations는 판단을 앞단으로 옮긴다
가장 넓은 워크플로도 일반적인 자문 경로에서는 소스를 직접 바꾸지 않는다. 시작 계약은 역량이 높은 모델에 판단이 쌓일수록 가치가 커지는 작업, 즉 모션 영역을 이해하고, 무엇을 고칠 가치가 있는지 결정하고, 명세를 작성하는 일을 맡긴다. 그런 다음 더 저렴한 모델을 포함한 다른 에이전트가 실행할 수 있게 한다(improve-animations/SKILL.md:6-10). 이 스킬의 강제 규칙은 계획에 정확한 맥락과 값을 담도록 요구하는 한편, 소스 수정과 상태를 바꾸는 작업은 금지한다(improve-animations/SKILL.md:20-24).
분석 퍼널은 명시적이다.
- 정찰이 먼저다. 자문 에이전트는 무엇이든 판단하기 전에 기술 스택, 모션이 자리한 곳, 기존 관례, 제품의 성격, 상호작용 빈도를 파악한다(improve-animations/SKILL.md:28-40).
- 점검은 여덟 범주를 다룬다. 작은 저장소보다 크면 읽기 전용 서브에이전트에 이 검사를 분산할 수 있고, effort level로 점검 범위를 조절한다(improve-animations/SKILL.md:42-63).
- 주 자문 에이전트는 인용된 모든 위치를 다시 읽고, 유효하지 않거나 중복된 지적 사항을 버린 뒤, 남은 항목을 파급력이 큰 순서로 정렬한다(improve-animations/SKILL.md:65-78).
- 선택한 지적 사항은 맥락이 전혀 없는 실행자를 위한 구현 계획이 된다. 계획에는 커밋 스탬프, 소스 원문, 정확한 대상, 저장소 내 모범 사례, 순서가 있는 수정 단계, 명확한 경계, 기계적 검사, 지각되는 느낌에 대한 검사가 들어간다(PLAN-TEMPLATE.md:3-65).
실행은 별도의 모드다. execute <plan>은 격리된 worktree의 실행자에게 작업을 보내고, 결과 diff를 review-animations의 기준에 맞춰 리뷰한다(improve-animations/SKILL.md:88-97). 계획은 비용이 높은 판단과 비용이 낮은 기계적 실행을 잇는 인터페이스다.
두 가지 예외가 진짜 계약을 드러낸다
깔끔한 요약만 내놓으면 틀리게 되는 지점이 두 군데 있었다.
첫째, 워크플로가 항상 사람의 선택을 기다리며 멈추는 것은 아니다. 대화형 실행에서는 어떤 지적 사항을 계획으로 만들지 사용자가 선택할 때까지 기다린다. 비대화형 실행에서는 파급력이 가장 큰 지적 사항 세 개에서 다섯 개를 기본값으로 고른다(improve-animations/SKILL.md:65-78). 이 아키텍처에는 사람의 체크포인트가 있지만, 사람이 지켜보지 않아도 결정론적으로 진행하는 방법도 정의되어 있다.
둘째, “지적 사항 하나당 계획 하나”는 기본값이지 절대적인 일대일 매핑이 아니다. 두 지적 사항이 모든 파일과 동일한 수정 패턴을 공유하면 하나로 합칠 수 있다(PLAN-TEMPLATE.md:68-72). 핸드오프 산출물은 계획을 중복해서 만들지 않으면서도 자체 완결성을 유지한다.
이것들은 편집상의 각주가 아니다. 저장소가 오케스트레이션 정책을 스킬 계약의 일부로 다룬다는 사실을 보여준다. 정상 경로뿐 아니라 경로가 바뀌는 조건까지 명시한다.
스킬 작성자가 재사용할 수 있는 것
재사용할 패턴은 “더 긴 전문가 프롬프트를 작성하라”가 아니다. 권한의 종류를 분리하는 것이다.
- 모호한 의도에는 작은 정규화 계층을 둔다.
- 범용 원칙과 도메인별 구현 깊이를 분리한다.
- 리뷰를 고정된 출력 스키마와 명시적인 결정을 갖춘 좁은 게이트로 만든다.
- 가장 강력한 모델은 정찰, 근거 확인, 우선순위 결정, 명세 작성에 사용한다.
- 구현에 필요한 모든 세부 사항을 기준 커밋이 명시된 핸드오프 산출물에 담는다.
- 상호작용과 병합 예외를 워크플로 안에 명시해 오케스트레이션이 추측하지 않게 한다.
더 넓은 에이전트 시스템 지도에서 보면, 이 저장소는 페르소나 프롬프트보다 컴파일러 파이프라인에 가깝다. 각 단계가 모호함을 줄이고 곧바로 실행에 옮길 수 있는 산출물을 내놓는다. 다만 이는 소스 수준의 해석이지 런타임 벤치마크가 아니다. 저장소는 계약이 어떻게 설계되었는지는 보여주지만, 더 약한 실행자가 의도한 모션 품질을 항상 보존한다거나 다섯 스킬로 나눈 구성이 프롬프트를 잘 짠 단일 모델보다 일관되게 뛰어나다는 점은 입증하지 않는다. 그 질문에는 실증 평가가 필요하다.
해당 커밋으로 고정한 소스가 입증하는 것은 더 좁고, 그래서 더 유용하다. 모션 감각이 이름, 원칙, 판정, 계획, 리뷰를 거친 실행 경로로 분해되어 있다는 것이다. 이것이 메커니즘이다. 단순한 Markdown 파일 모음이 아니다.