같은 주문, 두 번 시켰다

검수 질문은 하나다. 이 스킬을 깔면 산출이 실제로 달라지는가. 동일한 주문(shadcn 기반 프로젝트의 프로필 설정 페이지: 아바타, 이름·이메일 입력, 알림 수신 방식 선택, 마케팅 동의, 저장 중 상태를 가진 저장 버튼, 탈퇴 확인 다이얼로그)을 같은 모델로 스킬 없이 한 번, 장착하고 한 번 실행해, 나온 TSX를 17개 지표로 기계 대조했다.

• 금지 규칙 위반 7 → 0. 맨몸은 스킬이 금지하는 space-y 간격을 4곳에 썼고 로딩 상태를 Loader2·isLoading으로 손제작했다(3곳). 장착본은 전부 사라졌다. 간격은 flex+gap으로, 로딩은 정식 Spinner 조합으로
• 신형 문법 발현 0 → 22. 폼을 FieldGroup·Field·FieldDescription으로 짜는 신형 문법이 장착본에만 22회 나타났다. 맨몸은 이 컴포넌트의 존재 자체를 몰랐다
• Card 완전 조립 1 → 3. CardHeader·CardContent·CardFooter를 갖춘 조립이 3배가 됐다
• 맨몸도 기본기는 좋았다. 원색 하드코딩(bg-blue-500류) 0건, 탈퇴 확인에 AlertDialog와 Title을 제대로 썼다. 격차는 기본기가 아니라 최신 문법과 일관성 규율에서 났다

흥미로운 역설 하나. 시맨틱 토큰과 gap 클래스 수는 장착본이 오히려 적다. 규칙을 안 지켜서가 아니라, Field 같은 조립 컴포넌트가 스타일을 흡수해 손으로 쓰는 클래스 총량 자체가 줄었기 때문이다. 일관성의 진짜 모습은 "규칙을 많이 쓰는 것"이 아니라 "손댈 일이 줄어드는 것"이다.

스킬 작성의 현재 최고 수준

구성이 교본이다. SKILL.md 277줄은 원칙 4개(기존 컴포넌트 먼저, 조립하지 재발명하지 말 것, 내장 variant 먼저, 시맨틱 컬러만)와 금지 규칙들을 선언하고, 규칙마다 틀린 코드/맞는 코드 쌍을 담은 규칙집 6편(styling·forms·composition·base-vs-radix·icons·chat)으로 연결된다. 평가 스위트(evals)까지 동봉돼 있다.

가장 새로운 건 문맥 주입이다. SKILL.md 본문 안에서 CLI(npx shadcn info --json)를 실행해 이 프로젝트에 뭐가 설치돼 있는지를 스킬이 실시간으로 읽는다. 정적 문서가 아니라 프로젝트 상태를 아는 문서다. 허용 도구도 shadcn CLI 세 줄로 잠가 뒀다. 이번 재현 시리즈의 분류로는 도구 동봉형, 그중에서도 문맥 주입까지 간 최전선이다.

왜 이게 기준이 되는가

"AI로 UI를 만들 때 일관성이 무너진다"는 비개발자·기획자의 공통 고통이고, 이 스킬의 답은 기준을 코드로 주입하는 것이다. 기존 컴포넌트를 검색해 재사용하게 하고, variant를 쓰게 하고, 원색 대신 시맨틱 토큰을 강제한다. 우리 재현에서 그 규율이 실제 코드로 발현됨이 확인됐다. shadcn 기반 프로젝트(components.json이 있는 곳)에서는 별도 발동 걱정도 없다. 스킬이 자동으로 문맥에 들어가는 구조다.

같은 이유로 우리 UI 메뉴판(ui-menu)도 이번에 v0.4로 shadcn 이름 매핑 59항목을 달았다. 사람 말로 찾고("스르륵 나오는 메뉴"), shadcn 이름으로 시키는("Sheet로 만들어줘") 연결이 완성된다.

가져올 것과 주의

• shadcn 기반 프로젝트라면 사실상 필수다. init만 하면 따라온다
• 스킬을 만드는 사람에겐 이 구조가 교본이다. 규칙마다 틀림/맞음 코드 쌍, 프로젝트 상태 실시간 주입, 허용 도구 잠금, 평가 동봉
• 주의: shadcn이 아닌 프로젝트에선 규칙 절반이 무의미하다(Field·InputGroup은 shadcn 컴포넌트다). 그리고 스킬은 바를 올리지 검수를 대신하지 않는다. 장착본도 완벽하진 않았다