UI 디자인
에이전트가 화면을 요청받으면 화면을 작성합니다. 이 스킬은 그 양쪽의 간극을 메웁니다. 첫째, 표면이 무엇을 위한 것이며 어떻게 보여야 하는지 결정합니다. 그런 다음, 만들어진 것이 제 역할을 하는지 확인합니다.
아래 모든 것을 지배하는 두 가지 규칙이 있습니다. 첫 번째 파일보다 먼저 고객 결과에 이름을 붙이세요. 작동한다고 말하기 전에 실행 중인 제품을 확인하세요.
먼저 깊이를 선택하세요
| 변경 사항 | 단계 |
|---|---|
| 복사, 색상 하나, 속성 하나 | 1, 7, 그런 다음 결과 확인 |
| 하나의 컴포넌트, 하나의 상태 | 1, 4, 6, 7, 9 |
| 화면 하나, 양식 하나, 흐름 하나 | 0부터 10까지 간략히 |
| 새로운 표면, 또는 "이것을 현대적으로 만들어 줘" | 0부터 10까지 전체적으로, 3단계는 7단계 전에 승인받아야 함 |
| "이것을 감사해 줘" | ui-review를 사용하세요. 편집을 시작하지 마세요 |
| "...에 대한 컴포넌트를 찾아줘" | ui-find를 사용하세요 |
시작하기 전에 선택한 깊이를 한 줄로 말하세요. 변경 사항이 해당 단계가 보호하는 것에 도달할 수 없는 경우에만 단계를 건너뜁니다.
0. 사전 비행: 질문하기 전에 프로젝트를 읽으세요
다음 순서대로 읽고, 질문을 해결하는 첫 번째 항목에서 멈추세요.
- 프로젝트 루트의
DESIGN.md. 이미 존재하는 디자인 시스템은 이 스킬의 모든 기본값과 여러분 자신의 모든 취향보다 우선합니다. 그것을 따르세요. 작업에 파일이 다루지 않는 내용이 필요하면, 스타일시트에서 임의로 만들지 말고 해당 파일에 추가하세요. PRODUCT.md,README.md,.claude/, 기존 브리프.- 사용 중인 스택, 스타일링 시스템 및 컴포넌트 라이브러리.
- 가장 가까운 기존 화면과 이를 커버하는 테스트.
제품 자체의 시스템과 모순되는 화면은 발견 사항일 뿐, 세 번째 시스템을 시작할 권한이 아닙니다.
1. 디자인 시스템
references/design-system.md에는 형식과 두 가지 접근 경로가 있습니다.
| 프로젝트 상태 | 수행할 작업 |
|---|---|
DESIGN.md가 있음 | 그것을 읽고 따르며, 한 줄로 그렇게 했다고 말하세요 |
| 코드에 실제 디자인 시스템(토큰, 테마 파일, Tailwind config)이 있음 | 코드에서 값을 읽어 DESIGN.md로 코드화하세요. 절대 추측하지 마세요 |
| 라이브 제품 또는 브랜드가 있지만 문서화된 시스템이 없음 | 실제 제품에서 코드화하세요: 렌더링하고, 계산된 값을 읽고, 기록하세요 |
| 아무것도 없음 | 사용자가 선택한 방향에 따라 3단계에서 하나를 작성하세요 |
제품이 사용하지 않는 값을 명시하는 DESIGN.md는 절대 작성하지 마세요. 코드화된 시스템은 현재 있는 것의 기록입니다. 새로운 시스템은 제안이며, 사용자가 선택할 때까지 그렇게 표시됩니다.
파일을 기준으로 빌드하기 전에 다음을 실행하여 게이트하세요:
pnpm dlx @google/design.md lint DESIGN.md
이것은 실제 출판된 패키지입니다. 깨진 토큰 참조, 누락된 primary, 정의되지 않은 타이포그래피, 4.5:1 대비 기준 미만의 컴포넌트 색상 쌍을 잡아냅니다. 7단계 전에 보고된 내용을 수정하세요.
2. 고객 결과
references/product-thinking.md에는 방법이 있습니다. 비즈니스 결과, 고객과 그들의 작업, 가장 작은 유용한 버전. 각각 두 줄씩.
결과를 관찰 가능한 것으로 작성하세요:
40개의 열린 작업을 가진 디스패처가 목록을 떠나지 않고도 어떤 작업이 지연되었는지 확인하고 재할당할 수 있습니다.
그런 다음 각각 브라우저에서 확인할 수 있는 수락 기준을 작성하세요. "보기 좋음"은 기준이 아닙니다. "375px에서 모든 작업의 상태와 재할당 컨트롤이 가로 스크롤 없이 도달 가능함"이 기준입니다.
증거가 없는 경우, 가정을 작성하고 레이블을 붙이세요. 아무도 생성하지 않은 페르소나, 인용문 또는 전환 수치를 절대 작성하지 마세요.
3. 방향성 및 사용자의 선택
references/directions.md에는 방법과 용어가 있습니다.
세 가지 방향성을 제시하세요. 하나가 아닙니다. 단일 제안은 근거를 입은 모델의 기본 미학일 뿐입니다. 각 방향성은 이름, 앵커 색상, 타이프 페어링, 밀도, 기억에 남을 한 가지를 네 줄로 받습니다.
그런 다음 멈추고 대화형 질문 도구를 사용하여 사용자에게 제시하세요. 이것은 승인 게이트입니다. 가정에 기초하여 이를 넘어 빌드하지 마세요. 사용자가 "당신이 골라"라고 말하면 하나를 선택하고, 어떤 것과 그 이유를 한 줄로 말한 후 계속 진행하세요.
승인 시, 선택한 방향성의 실제 값으로 DESIGN.md를 작성하거나 업데이트하고 린트하세요.
4. 여정과 그 상태
references/journey-and-states.md.
이 표면이 실제로 가지는 상태를 나열하세요: 비어 있음, 항목 하나, 많음, 가장 밀도가 높은 실제 사례, 로딩 중, 부분 실패, 오류, 권한 없음. 하나의 픽스처를 기반으로 구축된 화면은 다른 모든 상태를 숨깁니다. 이것이 완성된 화면이 고객과 접촉할 때 실패하는 가장 흔한 이유입니다.
5. 컴포넌트를 작성하기 전에 찾으세요
ui-find를 실행하거나 스크립트를 직접 실행하세요:
node .claude/skills/ui-design/scripts/find-components.js <검색어> --limit 15
먼저 프로젝트 자체의 컴포넌트를 검색하세요. 제품이 이미 가지고 있는 컴포넌트를 두 번 구현하는 것은 결함입니다. 읽은 후보와 각각이 부적합했던 이유를 명명한 후에만 처음부터 컴포넌트를 작성하세요.
6. 목업 또는 실제 제품
사용자가 이미 말하지 않은 경우, 한 줄로 물어보세요. 두 경로 모두 실제 HTML과 CSS를 빌드합니다. 차이점은 파일이 위치하는 곳과 무엇에 연결되어 있는지입니다.
| 경로 | 사용 시기 | 위치 |
|---|---|---|
| 목업 | 새로운 표면, 리디자인, 이해 관계자를 설득해야 할 때, 또는 사용자가 요청할 때 | mock/ 아래의 독립 페이지, 실제 디자인 토큰과 샘플 데이터(샘플임을 명시) 사용 |
| 직접 | 라이브 제품 내부의 변경, 또는 사용자가 빌드하라고 할 때 | 제품 자체의 파일 |
목업은 승인된 후 제품의 컴포넌트로 재구축됩니다. 빌드하기 전에 이를 말하여 아무도 목업 파일이 배송될 것이라고 기대하지 않도록 하세요.
7. 빌드
해피 패스뿐만 아니라 4단계의 상태를 빌드하세요. 제품 자체의 토큰과 컴포넌트를 사용하세요.
첫 번째 UI 편집 직전에 매번(작은 편집도 포함) references/gates.md와 references/craft.md를 읽으세요.
gates.md는 최소 기준입니다: 모든 모델이 빠지기 쉬운 기본값과 대신 해야 할 일. craft.md는 그 위의 계층입니다. 테두리 대신 그림자로서의 깊이. 동심원 반경. 300ms 미만의 이즈아웃. 한 번만 발사되고 반복 상호작용에서는 다시 발사되지 않는 진입 효과. 표 형식 숫자. 화면의 두 부분이 연결되어 고객이 하나임을 알 수 있도록.
가장 중요한 화면 또는 히어로를 단독으로 먼저 빌드하세요. 나머지를 빌드하기 전에 새로운 시각으로 검토하세요: 결정에 대한 기억이 없는 하위 에이전트가 당신이 놓친 것을 잡아냅니다. 그런 다음 나머지를 빌드하세요.
8. 실행하고 살펴보세요
소스 리뷰가 아닙니다. 애플리케이션을 시작하고, 브라우저에서 열고, 실제 진입점에서 고객이 사용하는 것처럼 사용하세요.
references/playwright.md에는 메커니즘과 애플리케이션이 여기서 시작되지 않을 경우 해야 할 일이 있습니다.
스크린샷을 보세요. 파일 목록을 읽는 것은 보는 것이 아닙니다.
9. 검토 및 수정
빌드한 것에 대해 ui-review를 실행하세요. 라이브 렌더를 측정하고, 여정을 탐색하고, 결과를 DESIGN.md와 비교하고, 피해 순서대로 문제점을 정렬합니다.
심각도 순서로 수정하세요. 2단계의 결과에 대해 정당화할 수 없는 변경은 아무도 요청하지 않은 범위입니다. 무엇을 남겨두었고 그 이유를 말하세요.
그런 다음 references/regression.md: 코드를 건드리기 전에 이미 작동했던 여정을 식별하고, 변경으로 인해 발생한 실패와 원래 있던 실패를 분리하세요.
10. 보고
- 고객 결과 및 충족 여부.
- 선택한 방향성과 선택한 사람.
- 파일별로 빌드되거나 변경된 사항.
- 어떤 방법, 어떤 너비, 어떤 상태에서 검증되었는지.
- 검증되지 않은 사항과 그 이유.
- 수정된 발견 사항과 남겨둔 발견 사항 및 그 이유.
- 여전히 가정인 가정들.
정직함, 이는 위의 모든 단계보다 우선합니다
- 측정하지 않은 측정치나 렌더링하지 않은 화면을 절대 보고하지 마세요.
- 모든 대체물에 이름을 붙이세요. 라이브 데이터를 위한 픽스처, 애플리케이션을 위한 정적 페이지, 브랜드 폰트를 위한 로컬 폰트.
- 애플리케이션을 시작하거나 도달할 수 없는 경우, 그렇게 말하고 모든 여정 주장을 미검증으로 표시하세요. 소스가 실행되는 것을 본 것처럼 설명하지 마세요.
- 지표, 사용 후기, 로고 월 또는 고객 수를 절대 만들어내지 마세요. 실제 수치가 없는 경우, 레이블이 지정된 슬롯을 남기고 비어 있다고 말하세요.
- 뒤에 아무것도 없는 양식은 그 자체로 그렇게 말합니다. 보내지 않고 "전송됨"을 출력하는 페이지는 자리 표시자가 아니라 결함입니다.
- 직접 여정을 걸어보면 마찰을 발견합니다. 고객이 무엇을 하는지 측정하지는 않습니다.
이 스킬이 빌려온 것과 출처
NOTICE에 기록되어 있습니다. 컴포넌트 소스와 라이선스는 sources.json에 있습니다. scripts/check-sources.js는 해당 파일을 검증하고 tests/run.sh는 스크립트를 테스트합니다.