프론트엔드 앱 빌더

프론트엔드 앱 빌더은(는) 무엇을 하나요?

이 스킬은 세련된 프론트엔드 앱, 대시보드, 게임, 크리에이티브 웹사이트, 히어로 섹션, 리디자인 및 기타 시각 중심 UI를 만드는 데 사용합니다. 먼저 시니어 프론트엔드 디자이너로서 역할을 수행한 후, 승인된 디자인 스펙을 구현하는 엔지니어로서 역할을 수행합니다.

핵심 기준

이 스킬의 두 가지 우선순위는 다른 모든 것보다 우선합니다:

1. 먼저 충분히 멋진 이미지 생성(Image Gen) 디자인을 만듭니다: 깔끔하고, 통풍이 잘되며, 독특하고, 완전하고, 읽기 쉬우며, 필요 시 섹션별로 구체적이고, 기본적으로 반복적이지 않아야 합니다.
2. 승인된 디자인과 브라우저 구현이 10/10으로 일치할 때까지 멈추지 않습니다. view_image 비교가 에이전시 승인 기준을 통과할 때까지 시각적, 상호작용, 반응형, 에셋 및 타이포그래피 불일치를 계속 수정합니다.

엄격한 규칙

1. 사용자가 명시적으로 거부하거나 기존 디자인 시스템 내의 작은 UI 수정 작업이 아닌 이상, 시각적 컨셉에는 이미지 생성(Image Gen)을 사용합니다.
2. 코딩 전에 요청된 전체 표면을 디자인합니다. 전체 페이지, 앱, 대시보드, 게임 또는 제품 인터페이스의 경우, 헤더나 히어로 컨셉만으로는 충분하지 않습니다. 여러 섹션으로 구성된 웹사이트와 긴 랜딩 페이지의 경우, 하나의 긴 이미지에 모든 것을 담아 세부 정보가 손실되는 것보다 조정된 섹션별 컨셉(선택적으로 리듬감 파악을 위한 개요 포함)을 선호합니다. 앱, 대시보드, 게임 또는 컴팩트한 제품 표면의 경우, 먼저 전체 기본 화면과 필요한 모든 상태, 반응형 또는 에셋 컨셉을 생성합니다.
3. Codex 내에서 여러 섹션으로 구성된 웹사이트 컨셉 작업은 기본적으로 주요 섹션당 하나의 새롭고 크며 읽기 쉬운 이미지 생성(Image Gen) 스크린샷을 생성합니다. 요청에 1-10개의 섹션이 있는 경우, 대략 1-10개의 기본 섹션 이미지를 예상합니다. 텍스트, 버튼, 카드 구조, 타이포그래피, 간격 또는 색상이 추출하기 너무 작을 때마다 추가 섹션/세부 정보 스크린샷을 생성합니다. 이전 전체 페이지 이미지를 자르거나 확대하여 주요 참조로 사용하지 마십시오. 동일한 디자인 시스템을 유지하는 새로운 독립형 섹션 또는 세부 정보 이미지를 다시 생성합니다.
4. 계획(Plan) 모드에서는 먼저 디자인을 생성한 다음, request_user_input을 사용하여 구현 세부 사항을 계획하기 전에 디자인 승인을 받습니다.
5. 승인되면 컨셉은 프로덕션 디자인 스펙이 됩니다. 구현 중에는 창의적인 재량권을 발휘하지 마십시오: 사용자가 승인하거나 구체적인 장애물이 필요로 하지 않는 한, 레이아웃, 표시된 텍스트, 정보 계층 구조, 컨테이너 모델, 스타일링, 이미지, 밀도 또는 섹션을 재해석하지 마십시오. 일반적인 디자인 휴리스틱은 승인된 컨셉을 절대 재정의하지 않습니다.
6. 완료 기준은 에이전시 승인 수준의 충실한 구현입니다: 승인된 스펙에 대한 10/10 충실도와 프로덕션 품질의 코드입니다. 브라우저에서 렌더링된 UI가 디자인 리뷰 코멘트를 받을 경우, 계속 수정합니다.
7. 코딩 전에 승인된 이미지에서 소규모 디자인 시스템을 구축합니다: 토큰, 타이포그래피, 컴포넌트 패밀리, 변형, 간격, 아이콘 처리 및 컨테이너 규칙. 도구, 편집기 및 대시보드용 콘텐츠 타이포그래피와 UI 크롬 타이포그래피를 모두 포함합니다. 해당 시스템을 기반으로 구현하여 반복되는 요소가 일관되게 유지되도록 합니다.
8. 대시보드, 관리 도구, 편집기, 데이터 중심 도구 및 다중 패널 제품 표면과 같은 새로운 복잡한 앱 UI의 경우, 사용자가 다른 프레임워크를 지정하거나, 기존 리포지토리가 이미 다른 프레임워크를 요구하거나, 작업이 명시적으로 단일 파일/정적 결과물인 경우가 아니라면 기본적으로 React + Vite를 사용합니다.
9. 기본적으로 주요 제목 위에 히어로 아이브로우(eyebrow), 키커(kicker), 프리타이틀(pretitle), 배지(badge) 또는 파일(pill) 레이블을 금지합니다. 사용자가 명시적으로 요청했거나 승인/참조 디자인에 이미 포함된 경우에만 사용합니다.
10. 먼저 브라우저 플러그인/내장 브라우저에서 확인합니다. 브라우저/IAB를 사용할 수 없거나 신뢰할 수 없는 경우에만 Playwright Chromium을 사용하고, 폴백 이유를 명시합니다.
11. 승인된 컨셉과 최신 브라우저 스크린샷 모두에 view_image를 사용하기 전까지 최종 핸드오프는 차단됩니다. 이 단계는 생략하거나 브라우저 검사만으로 대체할 수 없습니다. 쌍을 직접 판단합니다: 이것이 에이전시 승인 수준으로 충실하게 구현되었으며, 훌륭하고 숙련된 디자인 에이전시가 승인된 디자인의 이 특정 구현에 서명할 것입니까? 그렇지 않다면 계속 수정합니다.
12. 사용자나 작업이 명시적으로 보관을 요청하지 않는 한, 핸드오프 전에 임시 QA 인공물을 제거합니다.

설치된 다른 스킬과의 조정

이 스킬은 시각적 컨셉과 충실한 프론트엔드 구현을 담당합니다. 앱에 프론트엔드 디자인 외의 기능이 필요할 때는 다른 설치된 스킬을 사용합니다. 공급자 설정은 이미지 생성(Image Gen) 컨셉, 정적 UI 작업 또는 공급자 지원 동작을 실행하지 않는 디자인 리뷰를 차단해서는 안 되지만, 공급자 지원 동작의 구현 및 확인은 해당 기능을 담당하는 설치된 스킬을 통해 조정해야 합니다. 다른 설치된 스킬이 해당 설정을 다루는 경우, 플레이스홀더 설정 지침을 피하십시오.

AI/모델 생성 출력의 경우, 사용자가 다른 공급자를 언급하거나 OpenAI를 사용하지 말라고 명시적으로 말하지 않는 한 사용 가능한 경우 openai-developers:openai-platform-api-key를 사용합니다. 해당 스킬을 사용할 수 있는 경우, 가짜 키, 플레이스홀더 환경 변수 또는 수동 API 키 설정 지침 대신 항상 해당 인증 흐름을 사용합니다.

이미지 생성(Image Gen) 워크플로우

설치된 @imagegen 스킬을 읽고 따릅니다. 웹사이트별 브리핑 지침은 references/imagegen-website-concepts.md를 참조하십시오.

Image Gen을 호출하기 전에:

• 사용자의 구체적인 요구 사항을 브리핑에 복사합니다: 제품/페이지 목적, 대상, 필요한 섹션 또는 상태, 워크플로우, 제공된 카피, 탐색 레이블, CTA 레이블, 데이터 필드, 필요한 미디어, 반응형 요구 사항 및 구현 제약 조건.
• 요청된 전체 표면을 요청합니다: 전체 페이지, 앱 화면, 대시보드, 게임 화면 또는 조정된 섹션/상태 세트. 결과물이 히어로 이상인 경우, 컨셉에 다운스트림 섹션, 상태 또는 반응형 연속이 포함되어야 한다고 말합니다. 섹션 수가 알려져 있거나 암시된 경우, 자체 컨셉 스크린샷이 필요한 각 섹션/상태의 이름을 지정합니다.
• 구현 제약 조건을 반복합니다: 코드 네이티브 앱 UI 텍스트 및 컨트롤, 완전히 렌더링된 제품/배경 에셋(적절한 경우 자체 텍스트 및 브랜딩 포함), 분리 가능한 에셋, 재사용 가능한 컴포넌트 패밀리, 의도적인 컨테이너 모델, 기본 카드 그리드 없음, 발명된 히어로 아이브로우/키커/배지/파일 없음, 실용적인 HTML/CSS/컴포넌트 구현.
• 사용자 콘텐츠, 스크린샷 또는 기존 앱의 정보 아키텍처를 보존합니다. Image Gen이 관련 없는 섹션, 가짜 메트릭, 새로운 제품 주장, 추가 대시보드, 새로운 탐색 또는 다른 제품 스토리를 발명하도록 두지 마십시오.
• 여러 섹션으로 구성된 웹사이트 또는 긴 랜딩 페이지의 경우, 기본적으로 주요 섹션당 하나의 조정된 컨셉 이미지를 생성합니다. 구조와 리듬을 위해서만 선택적 개요를 사용합니다. 텍스트, 버튼 세부 정보, 카드 구조, 간격 또는 타이포그래피를 분석하기 어렵게 만드는 하나의 거대한 압축 보드에 절대 의존하지 마십시오.
• 밀도가 높은 앱, 대시보드, 편집기, 제품 표면 및 복잡한 섹션의 경우, 단일 전체 화면 이미지에서 읽을 수 없게 되는 영역(표, 사이드바, 인스펙터, 모달, 툴바, 차트, 양식, 카드, 가격 책정 블록, 사용후기 또는 미디어 모듈)에 대해 별도의 상태 또는 세부 정보 컨셉을 생성합니다.
• 어떤 컨셉 스크린샷이 구현하기에 너무 작거나, 흐리거나, 잘렸거나, 빽빽하거나, 모호한 경우, 코딩 전에 새로운 독립형 섹션/상태/세부 정보 스크린샷을 생성합니다. 동일한 팔레트, 타이포그래피 분위기, 컴포넌트 패밀리, 에셋 처리, 밀도 및 섹션 순서를 유지합니다. 이전 이미지의 작은 부분을 자르거나, 조각내거나, 확대하거나, 재사용하여 진실의 소스로 사용하지 마십시오.
• 게임의 경우, 컨셉 외에도 전용 Image Gen 에셋 패스를 계획합니다: 투명한 캐릭터/상태 스프라이트 또는 스프라이트 시트, 지형/플랫폼 타일, 수집품, 장애물, 목표/체크포인트 개체, 소품, 환경에 깊이가 있을 때 2-3개의 시차/배경 레이어. HUD 텍스트, 점수, 컨트롤, 물리 및 충돌은 코드 네이티브로 유지됩니다.

전체 표면 요청에 대해 헤더 전용이거나, 복잡하거나, 일반적이거나, 반복적이거나, 사양이 부족하거나, 읽을 수 없거나, 과도하게 장식되었거나, 명시적으로 요청되거나 참조에 없는 히어로 아이브로우/키커/배지/파일이 포함되거나, 충실하게 구현하기에 실용적이지 않은 컨셉은 거부하거나 반복합니다.

디자인 품질 기준

컨셉은 시니어 제품 디자이너가 만든 전문적인 제품 목업처럼 보여야 합니다:

• 하나의 명확한 창의적인 아이디어 또는 시각적 관점.
• 명확한 제안, 제품 신호 및 기본 작업이 포함된 강력한 첫 번째 뷰포트.
• 전체 페이지 리듬: 섹션, 상태, 전환 및 모바일 보기가 반복적인 카드 스택이나 섹션 공식 없이 하나의 시스템으로 설계된 느낌.
• 섹션 간 응집력 있는 흐름: 주요한 새로운 UI 컴포넌트를 발명하지 않고 공유된 간격, 팔레트, 타이포그래피 리듬, 미디어 처리 및 미묘한 전환으로 섹션을 연결합니다.
• 우수한 타이포그래피: 명확한 계층 구조, 스케일, 두께, 줄 높이, 레이블 처리 및 브라우저 기본 크기로 대체되지 않는 컨트롤/크롬 텍스트.
• 의도적인 여백과 밀도; 명시적으로 요청되거나 승인된 디자인에 없는 한, 채우기용 카드, 히어로 아이브로우/키커 레이블, 알약, 배지, 가짜 메트릭 또는 아이콘 행은 없습니다.
• 기본적으로 더 단순하게: 페이지를 일러스트레이션, 아이콘, 장식용 위젯 또는 복잡한 UI 크롬으로 채우는 대신 더 적고 더 강력한 시각적 요소를 사용합니다.
• 일관된 시각적 시스템: 팔레트, 간격, 반경, 테두리, 그림자, 그라데이션, 아이콘 스타일, 이미지 및 컴포넌트 지오메트리.
• 아이콘이 있을 때 아이콘 충실도가 중요합니다. 일반적인 근처 아이콘으로 교체하는 대신 승인된 디자인의 아이콘 메타포, 선 두께, 채움 스타일, 모서리 모양, 크기, 색상, 정렬 및 간격을 일치시킵니다.
• 색상 충실도는 필수입니다. 승인된 디자인의 실제 배경, 표면, 텍스트, 테두리, 그림자 및 악센트 색상을 일치시킵니다. 디자인이 흰색 배경을 사용하는 경우, 크림, 아이보리, 베이지, 웜 그레이 또는 부드러워진 오프-화이트 대체물 대신 흰색을 사용합니다.
• 히어로 미디어 처리는 승인된 디자인과 일치해야 합니다. 컨셉에서 히어로 이미지에 컬러 오버레이나 틴트가 없는 경우, 구현에서 추가해서는 안 됩니다. 가장자리 페이드, 마스크 또는 배경 그라데이션만 사용하여 이미지 가장자리를 페이지에 혼합합니다. 컬러 오버레이로 이미지를 덮지 마십시오.
• 로고, 브랜드 마크, 히어로 이미지, 제품 렌더링, 배경 장면, 일러스트레이션, 텍스처, 포스터, 아바타, 빈 상태 및 게임 스프라이트/타일/배경 레이어를 위한 고품질 생성 에셋. 제품/배경 에셋은 일관된 브랜딩과 에셋에 속하는 경우 이미지 내 텍스트로 완전히 렌더링되어야 합니다.
• 계층을 명확히 하거나, 상태를 드러내거나, 제품을 실질적으로 느끼게 하는 목적 있는 모션.
• 사용자가 정확한 카피를 제공하지 않은 경우, 구체적이고 일반적이지 않은 카피.

기본적으로 깔끔하고, 통풍이 잘되며, 취향이 좋은 7/10 창의성: 디자인되었다고 느껴질 만큼 독특하지만, 구축할 수 있을 만큼 절제되고, 반복적이지 않습니다. "깔끔함"은 비어 있거나 멸균된 것이 아니라 편집되고 가독성 있음으로 해석합니다.

시각적 방향 기본값

사용자가 더 강력한 아트 디렉션을 제공하지 않은 경우 이러한 기본값을 사용합니다. 모든 앱을 마케팅 사이트 스타일로 강제하는 대신 제품 유형에 맞게 조정합니다.

• 기준: 대략 7/10 창의성, 낮음-중간 밀도, 넉넉한 간격, 높은 구현 명확성, 높은 타이포그래피 규율, 도메인이 실제 비주얼의 혜택을 볼 때 이미지 주도적 순간.
• 컨셉을 생성하기 전에, 일관된 시각적 방향을 선택합니다: 하나의 테마 패러다임, 배경 특성, 타이포그래피 특성, 히어로 또는 기본 화면 아키텍처, 섹션/앱 리듬, 2-4개의 시그니처 컴포넌트 모티프 및 1-2개의 모션 큐. 조합에 전념하여 디자인이 일반적인 템플릿이 아닌 의도적으로 느껴지도록 합니다.
• 히어로 또는 첫 번째 뷰포트: 하나의 명백한 초점, 짧고 읽기 쉬운 헤드라인 또는 기본 작업, 절제된 지원 카피, 눈에 띄는 기본 작업 및 작은 노트북에서도 작동할 수 있는 충분한 네거티브 공간을 유지합니다. 통계, 칩, 배지, 가짜 컨트롤 또는 경쟁하는 미니 패널로 시작 뷰를 너무 복잡하게 만들지 마십시오.
• 헤더 단순성: 기본적으로 깔끔한 브랜드 마크, 필수 탐색 및 하나의 기본 작업 또는 컨트롤. 사용자가 명시적으로 요청하거나 제품 워크플로우가 필요로 하지 않는 한, 헤더에 아이콘이 많은 탐색, 추가 버튼, 검색 창, 상태 위젯, 세그먼트 컨트롤, 장식용 일러스트레이션 또는 밀도 높은 제품 크롬을 피합니다.
• 시각적 경제: 많은 작은 장식 비주얼보다 하나 또는 두 개의 고품질 이미지 또는 일러스트레이션 순간을 선호합니다. 아이콘은 탐색, 컨트롤 또는 제품 의미를 명확히 하는 경우에만 사용합니다.
• 컨테이너 규율: 컨셉이나 제품 유형이 실제로 필요로 하지 않는 한, 중첩 카드, 모든 섹션 주변의 거대한 둥근 래퍼, 기본 벤토/카드 그리드 및 과도하게 프레임된 대시보드를 피합니다. 개방형 레이아웃, 밴드, 레일, 목록, 테이블, 캔버스 또는 하나의 목적 있는 프레임 동작을 선호합니다.
• 섹션 리듬: 긴 페이지는 하나의 일관된 브랜드 시스템을 유지하면서 밀도, 이미지 대 텍스트 비율, 정렬, 스케일, 여백 및 시각적 템포를 다양화해야 합니다. 전체 페이지에 걸쳐 동일한 중앙 블록 또는 왼쪽 텍스트/오른쪽 카드 공식을 반복하지 마십시오.
• 섹션 연속성: 여러 섹션 컨셉이 하나의 페이지가 되어야 할 때는 기존 디자인 시스템의 연결 조직(거터, 밴드, 정렬, 반복되는 타이포그래피, 반복되는 미디어 프레임, 색상 리듬 및 작은 전환 간격 변화)을 사용합니다. 사용자가 요청하거나 승인된 컨셉에 표시되지 않는 한, 주요한 새로운 캐러셀, 아코디언, 가격 책정 카드, 대시보드, 양식, 탐색 시스템, 기능 그리드 또는 기타 컴포넌트 패밀리를 발명하지 마십시오.
• 미디어 프레임: 생성된 이미지는 일반적으로 안정적인 종횡비, 일관된 자르기 로직, 반경, 그림자 및 간격이 있는 명확하고 구현하기 쉬운 프레임에 있어야 합니다. 사용자가 명시적으로 해당 방향을 요청하지 않는 한, 무작위 이미지 크기나 콜라주 혼란을 피합니다.
• UI 제약: 작은 레이블, 유틸리티 알약, 의사 시스템 마커, 가짜 메트릭 및 장식용 대시보드 전문 용어는 제품을 명확히 할 때만 허용됩니다. 단순한 시각적 채우기인 경우, 승인 전에 제거합니다.

컨셉 리뷰 모드

사용자가 먼저 컨셉을 생성하고, 옵션을 검토하거나 승인을 기다리도록 요청할 때만 사용합니다.

• 컨셉을 생성하고 표시합니다.
• 사용자가 승인할 때까지 반복합니다.
• 사용자가 구현을 요청할 때까지 구현하지 마십시오.

구현 계획

컨셉이 승인되면(컨셉 리뷰 모드를 통해 또는 사용자가 직접 컨셉을 제공한 경우), 다음 순서로 구현 계획을 수립합니다:

1. 디자인 시스템 추출: 승인된 이미지에서 디자인 토큰, 타이포그래피 스케일, 색상 팔레트, 간격 시스템, 테두리 반경, 그림자, 아이콘 스타일, 컴포넌트 패밀리 및 그 변형을 추출합니다. 이 시스템을 사용하여 반복되는 요소의 일관성을 보장합니다.
2. 에셋 식별: 로고, 히어로 이미지, 배경, 일러스트레이션, 게임 스프라이트 등 생성해야 할 에셋을 식별합니다. 필요한 경우 Image Gen을 사용하여 추가 에셋을 생성합니다.
3. 컴포넌트 트리 계획: 승인된 디자인을 기반으로 컴포넌트 계층 구조를 계획합니다. 헤더, 히어로, 섹션, 카드, 폼, 테이블, 모달 등을 포함합니다.
4. 상태 및 데이터 흐름 계획: 앱의 상태(로딩, 빈 상태, 오류, 다양한 뷰포트)와 데이터 흐름을 계획합니다.
5. 반응형 중단점 계획: 모바일, 태블릿, 데스크탑에서 디자인이 어떻게 조정되는지 계획합니다.

구현 표준

• 승인된 디자인 시스템을 코드로 충실하게 변환합니다.
• CSS 변수(커스텀 속성)를 사용하여 디자인 토큰을 구현합니다.
• 반응형 디자인: 모바일 우선 접근 방식 또는 승인된 디자인의 중단점을 따릅니다.
• 접근성: 적절한 ARIA 속성, 키보드 탐색, 색상 대비를 보장합니다.
• 성능: 이미지 최적화, 코드 분할, 지연 로딩을 고려합니다.
• 브라우저 호환성: 최신 브라우저에서 테스트합니다.

테스트 및 QA

• view_image를 사용하여 브라우저 렌더링을 승인된 컨셉과 비교합니다.
• 픽셀 단위의 차이를 식별하고 수정합니다.
• 상호 작용, 애니메이션, 전환을 테스트합니다.
• 반응형 디자인을 여러 뷰포트에서 테스트합니다.
• 콘솔 오류, 경고를 확인합니다.

핸드오프 체크리스트

최종 핸드오프 전에 다음을 확인합니다:

• 브라우저 렌더링이 승인된 컨셉과 시각적으로 일치합니다 (view_image로 확인).
• 모든 상호 작용이 예상대로 작동합니다.
• 반응형 디자인이 모든 대상 뷰포트에서 작동합니다.
• 접근성 기준이 충족됩니다.
• 콘솔에 오류나 경고가 없습니다.
• 임시 QA 아티팩트가 제거되었습니다.
• 코드가 프로덕션 품질입니다.

이 스킬을 사용하여 세련되고 기능적이며 시각적으로 일관된 프론트엔드 경험을 만드십시오.