taste-skill-swiftui은(는) 무엇을 하나요?

모델이 만든 앱 화면은 모델이 본 모든 앱 화면의 평균처럼 보입니다: 네 개 탭의 TabView, 큰 제목, 각각 틴트된 사각형 안에 SF Symbol이 있는 둥근 카드들의 List, 파란색 그라데이션 "시작하기" 버튼, 세 개의 심볼 페이지로 구성된 온보딩, 글로우가 있는 페이월. 그 안에 잘못된 것은 없지만 결정된 것도 없습니다.

이 스킬은 다음 네 가지 방법으로 이러한 기본값을 결정으로 대체합니다:

스크립트가 방향을 제시하고, 당신이 선택합니다. 룩을 만들라고 요청받으면 모델은 매번 카테고리 기본값을 선택합니다. scripts/draw.mjs는 연구된 12가지 방향 중 3가지를 제시합니다. 당신은 주제의 아이디어를 가장 잘 담은 방향을 선택하면, 타이포그래피, 팔레트, 형태, 모션 및 화면 청사진을 제시합니다.
아이디어는 주제에서 나옵니다. 최고의 앱은 스타일링이 아닌, 사물 자체(그 출력물, 그 대상, 그 의식, 그 인쇄물)에서 가져온 무언가 위에 구축됩니다.
네이티브 우선, 의도적일 때만 커스텀. 모든 요소는 사다리(아래 참조)를 오릅니다. 커스텀 컴포넌트는 허용되며 아이디어가 필요할 때 권장되지만, 모든 네이티브 동작을 구현해야 합니다.
당신이 만든 것을 봅니다. scripts/capture.sh는 기기 매트릭스(라이트/다크, 기본/접근성 글꼴)에서 앱을 촬영합니다. 심사위원의 평가 기준이 사진을 평가하고, 수정하고, 다시 확인합니다.

장식만 제거하는 것은 절반의 작업일 뿐입니다. 틴트된 사각형, 카드, 그라데이션을 잃었지만 아무것도 얻지 못한 화면은 얄팍합니다. 나머지 절반은 내용입니다: 더 크게 설정된 타이포그래피, 색상의 전체 필드, 이 주제 세계의 실제 사진이나 그려진 대상, 모든 화면이 전체 콘텐츠를 담고, 이 앱만이 할 수 있는 한 가지 사용자 동작이 있는 것.

아래 명령어에서 <skill>은 이 스킬의 폴더입니다. 프로젝트 루트에서 실행하고, 작업 파일은 .taste-skill/에 저장됩니다. 스크립트는 Node 18+가 필요합니다. capture.sh는 Xcode와 부팅된 시뮬레이터가 필요합니다. ~/.claude/bin/devlock이 존재하면 모든 xcodebuild와 simctl 실행을 devlock run으로 감싸세요(병렬 빌드가 이전에 프로세스 제한을 소진한 적이 있습니다).

네이티브 사다리

아이디어가 요구하는 만큼만 올라가고, 모든 3단계 컴포넌트를 보고서에 기록하세요.

시스템 컴포넌트, 시스템 룩. NavigationStack, TabView, List, Form, Toggle, Picker, Menu, ContentUnavailableView, detents가 있는 .sheet, ShareLink, Chart, ProgressView. 무료: Dynamic Type, VoiceOver, Reduce Motion, RTL, Liquid Glass, 키보드 및 포인터. 플랫폼의 역할을 하는 모든 컨트롤에 사용하세요.
시스템 컴포넌트, 스타일링됨. 동일한 컴포넌트, 당신의 토큰: ButtonStyle, LabelStyle, ToggleStyle, ListRowBackground, scrollContentBackground(.hidden), tint, fontDesign, fontWidth, containerShape. 대부분의 방향이 여기에 있습니다.
커스텀 컴포넌트. 시스템 컴포넌트가 아이디어를 전달할 수 없을 때만(다이얼, 자, 티켓, 무대, 타임라인 스파인). 커스텀 컴포넌트는 다음을 제공해야 합니다: @ScaledMetric/Font.custom(relativeTo:)를 통한 Dynamic Type, 44×44pt 최소 히트 영역, accessibilityElement(레이블, 값, 특성 및 조정 가능한 동작 포함), Reduce Motion 경로, sensoryFeedback을 통한 햅틱, 다크 모드, RTL(layoutDirection), iPad/Mac에서의 포커스 및 포인터 상태, 모든 상태에 대한 프리뷰. 설명문이 필요한 컨트롤은 캡션을 추가하지 말고 재설계하세요.

플랫폼이 소유한 것을 절대 다시 만들지 마세요: 손으로 그린 탭 바, 네비게이션 바, 스위치, 알림, 시트 또는 키보드 액세서리(아이디어가 없으면 안 되는 경우 제외). 블러 패널을 직접 만들지 마세요. Liquid Glass는 시스템 바, 툴바 및 부동 컨트롤의 시스템 유리 API에서만 제공됩니다.

웹에서 모바일로: 원본 규칙 매핑

Taste-skill (웹)	여기 (네이티브)
페이지 vs 앱 화면	앱은 거의 항상 두 번째 종류입니다. 첫 실행 화면, 온보딩 및 페이월은 구성된 화면(run을 따름)입니다. 목록, 설정, 양식 및 상세 화면은 작업 화면입니다(`references/screens.md` 참조).
히어로	실행 후 첫 화면(또는 홈 탭). "이게 뭐고, 어떻게 해야 하지"를 3초 안에 큰 타이포그래피나 큰 대상으로 답합니다.
모든 너비에서 최대 두 줄 헤드라인	iPhone SE 너비와 iPad에서 기본 크기로 두 줄, 접근성 크기에서는 줄 바꿈(절대 자르지 않음).
동일한 외부 여백, 웅크린 섹션 없음	시스템 레이아웃 여백(16/20pt)을 사용하세요. iPad와 가로 모드는 자체 구성(분할 보기, 사이드바, 두 열)을 가지며, 중앙에 맞춰진 폰 열은 절대 사용하지 않습니다.
실제 사진 바닥(4개)	주요 화면당 하나의 실제 또는 수제 시각 자료. SF Symbol은 기능적 글리프일 뿐, 그림이 아닙니다.
스크롤 장면	`scrollTransition`, `visualEffect`, `matchedGeometryEffect`, `navigationTransition(.zoom)`, `KeyframeAnimator`, `PhaseAnimator`, `TimelineView`.
라이브 대상	와우 모먼트: 이 앱만이 가지고 있는, 햅틱이 있고 한 손으로 작동하는 하나의 상호작용.
실제 브라우저의 `inspect.mjs`	시뮬레이터의 `capture.sh` + Swift 소스의 `lint.mjs`.
모션 바닥	첫 실행과 핵심 흐름 전반에 걸쳐 최소 6개의 의도적인 모션 모멘트. 각각 Reduce Motion 대체 수단 필요.
유리 없음	손수 만든 블러 카드 없음. 시스템 크롬의 시스템 유리는 괜찮음.
고정폭 없음	정렬된 숫자에만 `.monospacedDigit()` 사용. 코드 외부에서 `design: .monospaced` 절대 사용 금지.
얇은 구분선 없음	시스템이 그리는 목록 구분선은 괜찮음. 장식용 `Divider`, 1pt 윤곽선 카드 금지.
하단 = 디자인된 종료	긴 화면의 마지막 행, 또는 흐름의 종료 상태는 디자인되어야 하며, 빈 공간이 아니어야 합니다.

실행 순서

순서대로 수행하세요. 1~5단계는 몇 분이 걸리며 앱의 품질을 결정합니다.

1. 브리핑과 프로젝트 읽기

실제로 존재하는 것을 찾으세요: 주제, 대상, 사용자가 첫 1분 안에 해야 하는 한 가지 일, 플랫폼 및 배포 대상, 기존 디자인 시스템이나 토큰, 실제로 존재하는 에셋(사진, 제품 샷, 일러스트레이션, 영상, 이미지 도구), 리디자인에서 유지되어야 할 것(모델, 인텐트, 위젯, 구매, 현지화). 없는 에셋을 기준으로 계획하지 마세요. 요청이 모호하면 한 줄로 결정하고 판단을 명시하세요. 누락된 사실이 작업을 막을 때만 질문하세요.

주제 인벤토리 작성: 이 클라이언트에 속하고 경쟁사에는 없는 8~12가지 것들. 이름과 의미; 브리핑의 숫자(분, 그램, 가격, 연속 기록); 함께 살아가는 제약(하루 한 번, 오프라인, 한 번의 탭); 재료와 색상; 의식과 시간; 그 세계의 인쇄물(티켓, 라벨, 영수증, 시간표, 여권 스탬프); 소리; 물리적 제스처(흔들기, 불기, 길게 누르기). 4단계의 아이디어는 이 목록에서 나옵니다.

2. 주장 작성하기

앱을 주장과 증명으로 나열하세요. 첫 실행 및 핵심 흐름의 각 화면당 한 줄:

화면: 주장 -> 사용자가 증명으로 보거나 하는 것.

주장이 없는 화면은 삭제하세요. 이렇게 하면 스플래시, 온보딩 3페이지, 권한 요청, 페이월, 4개 탭 바의 기본 시퀀스를 피할 수 있습니다. 온보딩은 사용자가 핵심 작업을 한 번 할 수 있게 해줄 때만 자격이 있습니다.

3. 방향 그리기

node <skill>/scripts/draw.mjs --kind <kind> --brief "<주제에 대한 한 줄>" \
  --screens <주장 순서의 역할> [--tone <tone>] [--have <assets>] \
  [--keep palette,type] [--platform ios|ipad|watch|mac|vision] --options 3

이 명령은 3가지 방향을 제시합니다. 각각을 인벤토리와 비교하세요. 어떤 것이 이 클라이언트만의 무언가를 담을 수 있습니까? 가장 익숙한 것이 아닌 그 방향을 선택하고, 그 이유를 한 줄로 작성하세요. 그런 다음 전체 시트를 그립니다:

node <skill>/scripts/draw.mjs <--options 없이 동일한 인수> --direction <선택한 id>

--kind: node <skill>/scripts/draw.mjs --list kinds (유틸리티, 건강, 금융, 게임, 키즈, 소셜, 미디어, 생산성, 라이프스타일, 창의, 커머스, 기타).
--screens: --list roles의 역할 (온보딩, 홈, 상세, 생성, 결과, 설정, 페이월, 비어있음).
--tone: 조용함, 대담함, 따뜻함, 기술적, 장난기, 럭셔리, 에디토리얼. 브리핑이 요청할 때만.
--have: 존재하는 에셋: photography, product-photo, illustration, video, 3d. 없으면 생략하세요. 그리기는 이에 의존하는 구성을 피합니다.
--keep palette,type: 브랜드나 디자인 시스템이 이미 고정했을 때. 그리기는 구성, 형태, 모션만 처리하고, 시스템 값을 역할에 매핑합니다.
--seed <n>은 그리기를 반복 가능하게 만듭니다. 시트는 사용된 시드를 출력합니다.

팔레트를 주제와 비교하세요. 제시된 팔레트는 색상만큼이나 비율(하나의 바탕색, 하나의 잉크색, 하나의 강조색, 선택적 필드)의 집합입니다. 주제 자체의 재료와 충돌하면 한 번 다시 그리거나, 비율을 유지하고 주제에서 색상을 가져와서 그렇게 명시하세요.

4. 아이디어 찾기

방향은 구성하는 방식입니다. 아이디어는 앱을 이 주제에 속하게 만드는 것입니다. 빌드하기 전에 주제 자체에서 두 가지 빈칸을 채우세요:

이 앱에서, **[주제에 속하는 무언가]**는 **[방향이 요구하는 장치]**가 됩니다.

다음에서 찾으세요: 그 출력(생산하는 것, 재료로 표시), 그 대상(실루엣으로 형태), 그 이름(그림을 담은 글자), 그 장소, 그 의식(앱이 수행하는 순서), 그 인공물(티켓, 라벨, 영수증), 그 반대.

경쟁사 테스트: 가장 가까운 실제 경쟁사를 문장에 넣어보세요. 그래도 작동한다면, 아이디어는 카테고리에 속합니다. "깔끔하고 현대적인"은 아이디어가 아닙니다.

와우 모먼트(라이브 대상). 앱에 각 사용마다 다른, 아이디어에서 만들어진 하나의 상호작용을 부여하세요: 마이크에 불어서 촛불이 꺼지게 하기; 복용량을 설정하고 실제 반감기 곡선 읽기; 폰을 접으면 카세트가 재생되기. 실제 콘텐츠를 사용하고, 한 손으로 엄지로 작동하며, sensoryFeedback을 통한 햅틱, Reduce Motion 경로가 있고, 작업을 절대 차단하지 않습니다. 하나의 일이며, 놀이터가 아닙니다. 6단계에서 구축되며, 마지막에 모션으로 추가되지 않습니다.

5. 단어 쓰기

뷰보다 먼저 전체 카피 덱(일반 텍스트)을 references/copy.md에 따라 작성하고, 첫 번째 커밋부터 모든 문자열을 String Catalog(Localizable.xcstrings)에 넣으세요. 모든 제목은 기본 크기에서 두 줄에 맞아야 합니다. 화면당 하나의 기본 동작, 그것이 하는 일에 따라 이름을 지정하세요("시작하기", 아무 것도 없는 "계속", "더 알아보기" 금지). 비어 있음, 오류, 권한 카피는 지금 작성하고 나중으로 미루지 마세요. 증명은 절대 꾸며내지 마세요: 가짜 리뷰, 사용자 수, 수상 내역, 보도 자료 금지.

6. 여전히 구축하기

머릿속에서 모션을 끄고 구축하세요. 작업 순서:

토큰. 시트의 Palette/Theme을 라이트/다크 변형이 있는 에셋 카탈로그 색상(또는 ShapeStyle 토큰 열거형), Typography 열거형, Metrics 열거형(간격, 반경, 하나의 형태 규칙)으로 만듭니다. 모든 하위 항목은 토큰만 참조합니다. 뷰에서 Color(red:), .font(.system(size: 17)) 금지.
첫 번째 화면, 청사진이 설명하는 그대로, SE 너비, 표준, Pro Max 및 iPad에서. 다른 모든 것보다 먼저 큰 것은 크게, 작은 것은 작게 만드세요.
각 화면을 청사진에서 이 프로젝트의 콘텐츠로 만듭니다. 인접한 화면은 레이아웃을 공유해서는 안 됩니다. 아이디어를 모든 화면(설정, 페이월, 빈 상태 포함)에 적용하세요. 가장 흔한 실수는 독특한 홈 다음에 기본 Form이 오는 것입니다.
이미지, 선호도 순: 프로젝트 자체의 것; 생성된 것(이미지 도구가 있는 경우); 라이선스가 기록된 오픈 컬렉션의 주제 세계 실제 사진(references/imagery.md); 코드로 그린 것(Shape, Canvas, Path, 팔레트의 일관된 평면 그래픽 언어로); 타이포그래피와 색상만. SF Symbol은 기능적 글리프로만 사용하세요.
와우 모먼트(4단계에서), 주장을 증명하는 화면에서.
충만함. 각 화면을 포스터처럼 보세요: 하나의 지배적인 것과 그것이 담고 있는 콘텐츠. 대부분 비어 있는 바탕의 화면은 덜 만들어진 것입니다. 본문 이상의 전체 잉크로 실행되는 텍스트.
프레임. 하나의 여백 시스템. 모든 화면에는 제목(네비게이션 제목 또는 큰 디스플레이 제목)이 있고, 모든 목록 섹션에는 이름을 지정하는 헤더가 있습니다.
상태 및 의미. 모두: 로딩, 비어 있음, 오류, 오프라인, 권한 거부됨, 성공, 비활성화, 첫 실행, 긴 콘텐츠, 접근성 크기, RTL. 실제 Buttons, 보이는 포커스, 레이블, accessibilityHint(레이블이 전달할 수 없는 경우에만), VoiceOver 순서, Reduce Motion 및 Increase Contrast 준수.
플랫폼 기준선(전역 규칙에서): en-US, en-GB, en-AU, en-CA 및 es-MX가 포함된 String Catalog; 긍정적인 순간이 지난 후에만 requestReview, 카운터와 설치 후 일수로 제한, 버전당 한 번; 햅틱; 다크/라이트; 앱에 핵심 동작이 있는 경우 App Intents.

결정 뒤의 세부 사항이 필요하면 references/type.md, colour.md, layout.md 및 components.md를 읽으세요. 아래 법칙은 짧은 형식입니다.

7. 게이트

node <skill>/scripts/lint.mjs <Swift 파일 또는 폴더>
<skill>/scripts/capture.sh <번들 id> .taste-skill/capture   # 부팅된 시뮬레이터

lint.mjs는 Swift 소스에서 금지된 패턴, 표준 문구 및 누락된 기준선(String Catalog, Reduce Motion, 햅틱)을 검색합니다. capture.sh는 각 부팅된 시뮬레이터에서 설치된 앱을 라이트/다크 모드와 기본/접근성 크기로 실행하고 스크린샷을 저장합니다. 모든 FAIL을 수정하세요. 각 WARN은 디자이너에게 한 문장으로 방어할 수 없다면 잘못된 것으로 간주하세요. FAIL이 없을 때까지 다시 실행하세요. 한 줄은 특정 규칙에 대해 트레일링 주석으로 옵트아웃할 수 있습니다.

taste-skill-swiftui