design

name	design
description	Use when doing UI design work in this project — 새 화면·컴포넌트 디자인, 스샷/레퍼런스 기반 UI 요청("이거처럼 만들어줘"), 디자인 방향이 열려 있는 UI 변경. 레퍼런스 유무와 무관하게 적용 — 디자인 스펙 확정까지의 절차(입력 분기, 레퍼런스 해석, 방향 옵션 제시, 목업 확인, 규모별 구현 연결)를 제공한다. Triggers on 스샷 첨부 UI 요청, "디자인하자", "화면 새로 만들자", "이런 느낌으로 바꿔줘". Does NOT trigger on 이미 확정된 디자인 스펙의 구현만 할 때(implement 영역), 비 UI 작업, 방향 판단이 필요 없는 단순 색·문구 교체.

Design — TodoCalendar 디자인 프로세스

목표는 기존 룩앤필 정합이다. 새 시각 정체성을 만들지 않는다 — 모든 산출은 기존 ViewAppearance 토큰(ColorSet·FontSet)과 CommonPresentation 컴포넌트 어휘 안에서 표현한다.

0. 입력 분기

• 레퍼런스 있음 (스샷·타 앱 화면·목업 이미지) → §1 레퍼런스 해석부터
• 지시만 있음 → frontend-design 스킬을 방향 생성에 활용하되 벡터를 뒤집는다: 그 스킬의 "누구와도 구별되는 새 정체성" 지향은 이 프로젝트에서 무효. 토큰 시스템을 새로 만들지 않고 기존 ColorSet/FontSet을 쓰며, 시그니처 요소도 기존 앱 톤 안에서 고른다. 차용하는 것은 브레인스톰 절차(레이아웃 개념 비교·타입 역할 구분·시그니처 하나에 집중·셀프 크리틱)뿐이다. 산출을 §2 방향 옵션으로 정리한다.

1. 레퍼런스 해석

스샷·레퍼런스에서 다음을 추출해 디자인 스펙으로 정리한다:

• 레이아웃 구조 — 계층·정렬·구획 (ASCII 와이어프레임 가능)
• 컴포넌트 매핑 — 각 요소를 CommonPresentation 기존 컴포넌트(ConfirmButton·BottomSlideView·CloseButton 등)에 먼저 대응시키고, 대응 안 되는 것만 신규 후보로 표시
• 토큰 번역 — 색은 colorSet.{...}, 폰트는 fontSet.{...} 프로퍼티로. 레퍼런스의 raw 색상값을 그대로 옮기지 않는다
• 인터랙션 — 탭·스와이프·전환·상태 변화
• 의도적 차이 — 레퍼런스가 기존 앱 톤과 충돌하는 부분은 정합 쪽으로 조정하고, 조정했다는 사실을 스펙에 명시한다

2. 방향 결정 — 옵션 제시

방향이 열려 있으면 옵션 2~3개를 제안한다. 각 옵션에 반드시:

• 기존 앱 톤과의 정합도
• 트레이드오프 — 구현 비용·기존 컴포넌트 재사용 정도·확장성

유저 선택으로 확정한다. 임의로 정하지 않는다.

3. 목업 확인 — 구현 전 이해 일치

확정 방향의 디자인 스펙을 **시각 목업(HTML)**으로 렌더해 유저 확인을 받는다:

• 목업 색·폰트는 기존 colorSet/fontSet 근사값 사용, 다크/라이트 양쪽 모두
• 목적은 구조·톤의 이해 일치 확인 — 픽셀 정확도가 아니다
• 유저 승인으로 디자인 스펙이 확정된다. 승인 전 구현 착수 금지

4. 구현 연결 — 규모별 분기

• 작은 UI 수정 (컴포넌트 1~2개, 기존 화면 내 변경) → 확정 스펙을 갖고 바로 구현 (implement 스킬 경로, 즉흥 수정)
• 화면 단위 이상 (새 Scene, 여러 화면에 걸친 변경) → 이슈 따서 kickoff 경유 — 확정 디자인 스펙이 이슈 본문과 플랜의 입력이 된다

어느 쪽이든 구현은 presentations-rules(토큰 강제·컴포넌트 재사용·Scene 6파일 구조)를 따른다.

5. 검증

• 기본: 빌드 가능 상태까지 만들고, 실제 화면 확인은 유저 육안(시뮬레이터/기기) — 피드백 핑퐁으로 보완한다
• 기계 검증: snapshot-check 스킬로 대표 케이스 스냅샷(라이트·다크 pair)을 떠 스펙과 대조한다. 외부 설명용 화면 촬영은 app-catalog 스킬.